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ABSTRACT 


“The  Defense  Science  Board  and  other  major  studies  have  concluded  that  one 
of  the  key  means  for  ensuring  interoperable  and  cost  effective  military  systems  is  to 
establish  comprehensive  architectural  guidance  for  all  of  DoD.  ” 

USD  (A&T),  ASD  (C3I),  JS/J6 
Memorandum 
Subject:  DoD  Architecture  Coordination 
Council  (ACC),  14  January  1997 

Northrop  Grumman  Ship  Systems  has  recently  been  awarded  the  Coast  Guard 
Deepwater  project  to  produce  three  classes  of  ships:  the  Maritime  Security  Cutter,  Large 
&  Medium  (WMSL  &  WMSM  )  and  Maritime  Patrol  Coastal  (WPC).  The  System 
Architecture  Description  Document  (SADD),  which  describes  architectural  framework 
that  is  used  to  establish  the  rules,  guidance,  and  product  descriptions  for  developing  and 
presenting  architecture  descriptions  that  ensure  a  common  denominator  for 
understanding,  comparing,  and  integrating  architectures  needs  to  be  written  for  the  WPC. 
The  SADD  has  been  written,  established  and  contractual  agreed  upon  for  both  the  Large 
and  Medium  Cutters.  However,  their  missions  dictate  that  they  have  littoral  capabilities 
and  the  capacity  to  conduct  missions  with  naval  vessels;  therefore  the  C4ISR  architecture 
was  chosen  for  their  SADD  as  it  fits  their  mission  statements.  The  mission  of  the  WPC  is 
of  a  different  nature.  It  is  not  expected  to  carry  out  the  same  functions  as  the  larger 
cutters  and  its  capabilities  will  be  more  of  a  littoral  function.  Therefore  the  application  of 
its  architectural  Framework  will  enable  architectures  to  contribute  most  effectively  to 
building  an  interoperable  and  cost  effective  system  subject  to  the  needs  of  the  WPC 
mission. 

This  thesis  proposes  to  compare  two  different  architectural  frameworks  for  use  by 
the  WPC’s  SADD:  1)  DoD  Architecture  Framework  and  2)  Zachman  Architecture 
Framework.  The  thesis  will  compare  and  recommend  the  architectural  framework  that 
will  at  most  enhance  the  mission  statement  set  forth  by  the  Original  Requirements 
Document  (ORD)  of  the  WPC. 
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EXECUTIVE  SUMMARY 


In  the  mid  1990s,  the  United  States  Coast  Guard  commissioned  a  study  to  analyze 
their  existing  assets,  capabilities,  future  needs  and  acquisition  strategy.  It  was  determined 
that  the  USCG  mission  needs  exceeded  the  capabilities  of  their  existing  assets. 
Moreover,  the  USCG  had  been  replacing  acquiring  platforms  on  a  need  basis  -  when  one 
asset  wore  out,  the  service  acquire  an  asset  to  replace  it  -  a  one-to-one  swap.  The 
commission  quickly  surmised  that  that  practice  was  slowly  relegating  the  USCG  to  an 
inferior  role  in  its  position  of  homeland  protection.  They  reported  that  unless  a  major 
acquisition  was  sought,  the  USCG  would  not  have  the  assets  and  platforms  to  accomplish 
its  major  missions. 

An  Integrated  Deepwater  System  (IDS),  headed  by  Northrop  Grumman  and 
Lockheed  Martin  Corporations,  was  incorporated  to  assist  in  the  USCG  acquisition 
strategy.  The  USCG  and  the  IDS  determined  that  three  classes  of  cutters  would  need  to 
be  built  and  they  are:  1)  the  WMSL  -  large  cutter,  2)  the  WMSM  -  the  medium  sized 
cutter  and  3)  the  WPC  -  patrol  cutter.  The  WMSL  and  WMSM  will  have  soft-kill 
capabilities,  be  able  to  be  fully  interoperable  with  the  United  States  Navy  command  and 
be  able  to  deploy  for  long  periods  of  time.  The  WPC  is  a  smaller  craft  that  is  used  for 
interdiction  purposes  and  law  enforcement.  It  is  able  to  deploy  5  days  as  opposed  to  the 
230  day  deployment  of  both  the  WMSL  and  WMSM. 

Based  on  mission  need,  capabilities,  relevance  and  required  performance  of  the 
WPC,  this  thesis  compares  two  architecture  frameworks:  the  DoD  Architecture 
Framework  and  Zachman  Framework  for  use  as  the  primary  architecture  for  developing 
its  System  Architecture  Description  Document  (SADD). 

A  study  of  the  DoDAF  and  Zachman  framework  included  purpose,  history  and 
capabilities  of  the  documents.  The  methodologies  for  research  included  initial 
expectations,  pros  and  cons  of  the  two  documents,  comparison  of  the  frameworks  and 
developing  a  survey. 
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After  polling  sixty-seven  directors,  managers  and  supervisors  (of  which  eighteen 
responded)  and  analyzing  their  responses,  it  was  determined  that  the  DoDAF  is  the 
architecture  framework  of  choice  for  men  and  women  that  work  in  the  defense  industry. 

After  comparing  the  frameworks,  analyzing  the  mission  needs  of  the  WPC  and 
determining  that  the  USCG  and  U.S.  Navy  leaders  are  determined  to  make  their  services 
interoperable  and  interconnected,  this  thesis  recommended  the  DoDAF  be  the  framework 
used  to  develop  the  WPC’s  SADD. 

Several  flaws  were  identified  within  the  DoDAF  and  recommendations  were 
made  to  overcome  them  and  some  modifications  were  recommended  to  enhance  the 
viability  of  the  framework. 

This  thesis  recommends  that  future  studies  be  conducted  to  combine  the  DoD 
business  frameworks  with  the  DoDAF  to  capture  the  business  aspects  of  enterprise 
development. 
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I. 


INTRODUCTION 


A.  BACKGROUND 

The  United  States  Coast  Guard  (USCG)  has  been  protecting  the  property  and  lives 
of  Americans  since  their  incorporation  in  1790.  Then  as  now,  the  agency  used  the  best 
products  available  to  them  to  accomplish  their  mission.  Due  to  an  increase  in  drug 
patrolling,  war  fighting,  and  interdiction  related  activities  during  the  last  two  decades  the 
USCG  has  started  to  experience  a  growth  in  their  deepwater  responsibilities.  The  USCG 
has  many  different  roles  varying  from  Maritime  Law  Enforcement,  Maritime  Safety, 
National  Defense,  and  Marine  Environmental  Protection.  All  of  the  roles  stated  are 
performed  in  the  deepwater  arena  and  this  has  put  a  strain  on  the  USCG’s  aging 
resources. 

In  the  mid  1990’s  the  USCG  commissioned  a  mission  analysis  to  be  done  to 
access  their  needs  and  a  Deepwater  Mission  Analysis  Report  was  submitted  to  the  Chief 
of  the  Office  of  Law  Enforcement  and  Defense  Operation  on  November  6,  1995.1  This 
report  contained  a  summary  of  each  role  (as  stated  above)  and  each  role’s  mission, 
current  asset  capabilities  to  meet  each  mission,  mission  performance,  and  future  demands 
to  accomplish  missions.  The  report  was  quite  extensive  in  its  projections  that  the 
USCG’s  ability  to  continue  to  conduct  its  overall  mission  was  limited  by  its  aging 
resources  which  were/are  rapidly  approaching  the  end  of  their  service  lives. 

In  the  past  the  USCG  procured  ships,  helicopters  and  other  resources  as  they 
became  obsolete  or  insupportable  on  a  platform  class  by  platform  class  basis,  on  a  one-to- 
one  basis.  This  approach  limited  the  agency’s  ability  to  keep  up  with  technological 
advances,  avoided  long  range  re-acquisition  planning,  wasted  money  by  not  having  an 
acquisition  plan,  and  did  not  consider  overall  integrated  asset  capabilities.  The  old 
acquisition  approach  used  by  the  USCG  has  tended  to  leave  the  agency  over-utilized 
without  the  resources  to  completely  fulfill  its  roles.  Growing  maintenance  requirements 
place  greater  demands  on  the  logistics  infrastructure  already  stretched  too  thin  and  asset 
operational  availability  continues  to  decrease  as  cutters  and  aircraft  spend  more  time  at 
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the  pier  and  in  the  hangar.  Older  maintenance  needy  and  technologically  archaic  assets 

'J 

require  larger  and  necessarily  more  expensive  crews. 

To  continue  to  meet  America’s  21st  century  maritime  threats  and  challenges,  the 
Coast  Guard  initiated  the  Integrated  Deepwater  System  (IDS)  program,  the  largest  and 
most  innovative  acquisition  program  in  USCG  history.4  The  IDS  is  a  long-term  project 
with  full  implementation  scheduled  for  2022.  In  that  time  the  IDS  will  have  upgraded 
some  existing  assets  and  made  the  transition  to  new,  more  capable  platforms  with 
systems  that  have  greater  command,  control,  communications,  computers,  intelligence, 
surveillance,  and  reconnaissance  (C4ISR)  and  innovative  logistics  support.  The  USCG  is 
teaming  with  the  Navy  to  support  the  National  Fleet  Policy  to  ensure  that  all  IDS 
platforms  and  systems  are  interoperable,  non-redundant  and  absolutely  compatible  to 
attend  to  the  Nation’s  maritime  security  and  defense  needs.5 

The  purpose  of  the  IDS  is  to  concentrate  on  system-wide  capabilities  and  not 
assets  as  the  old  acquisition  strategy  did.  The  IDS  is  a  joint  effort  between  Northrop 
Grumman  Corporation  and  Lockheed  Martin:  A  partnership  formed  to  be  a  system 
integrator  and  to  serve  as  the  USCG’s  service  partner.  The  IDS  will  analyze  existing 
assets  and  then  upgrade  or  retire  assets,  while  introducing  new  assets  in  the  form  of 
cutters  and  aircraft. 

Northrop  Grumman  Corporation  is  tasked  with  building  or  overseeing  the 
construction  of  three  classes  of  cutters  for  the  USCG:  The  Maritime  Security  Cutter, 
Large  (WMSL),  Maritime  Security  Cutter,  Medium  (WMSM)  and  Maritime  Patrol 
Coastal  (WPC). 

The  WMSL  is  415  foot  in  length,  displacement  of  4,300  long  tons  (LT),  range  of 
12,  000  nautical  miles  (NM),  sustained  speed  of  28  knots  and  provisional  endurance  of  60 
days.  During  times  of  war  the  WMSL  will  come  under  direct  Navy  command  and  is 
designed  to  deploy  230  days  per  year.  This  cutter  has  soft-kill  capabilities  and  deploys 
with  two  aircraft. 

The  WMSM  is  350  foot  in  length,  displacement  of  2,921  LT,  has  a  range  of  9,000 
NM,  sustained  speed  of  26.5  knots  and  provisional  endurance  of  45  days.  During  times 

of  war  the  WMSM  will  come  under  direct  Navy  command  and  is  designed  to  deploy  230 
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days  per  year.  This  cutter  also  has  soft-kill  capabilities  and  deploys  with  two  aircraft. 

The  WPC  is  140  foot  in  length,  a  displacement  of  200  LT,  a  range  of  (less  than) 
5000  NM,  sustained  speed  of  30  knots  and  provisional  endurance  of  5  days.  This  cutter 
can  be  deployed  independently  in  support  of  law  enforcement,  port  security,  search  and 
rescue,  and  defense  operations  missions.  Typical  missions  include  near-shore  fisheries, 
choke  point  interdiction,  barrier  patrols,  and  providing  a  show  of  presence  in  areas  of 
concern.6 

The  WPC  mission  and  capabilities  differ  in  large  part  from  the  WMSL  and 
WMSM  and  therefore  it  is  possible  that  its  system  of  system’s  architecture  document  can 
deviate  from  the  architecture  document  of  the  larger  cutters,  which  is  based  upon  the 
Department  of  Defense  Architecture  Framework  (DoDAF),  which  has  at  its  heart  the 
C4ISR  system. 

B.  PURPOSE 

The  purpose  of  this  thesis  is  to  determine  which  of  two  architecture  frameworks  - 
the  DoDAF  or  the  Zachman  should  be  used  to  develop  the  System  of  Systems 
Architecture  Document  (SADD)  for  the  USCG’s  WPC.  The  criteria  for  selection  of  an 
architecture  framework  will  be  based  on  WPC’s  mission  need,  capability,  entrance  and 
exit  criteria,  alternatives,  relevance  and  performance  as  stated  by  the  USCG  in  their 
initial  requirements  documentation.  This  research  will  evaluate  the  above  named  criteria 
using  a  system  architecture  approach.  The  objective  is  to  determine  the  advantages  and 
disadvantages  of  each  framework  in  relation  to  mission  needs  of  the  WPC.  Research  will 
analyze  each  architecture  framework  in  relation  to  the  mission  of  WPC.  Research  will 
also  analyze  standard  operating  methods  of  each  framework.  A  comparison  of  each 
architecture  framework  will  be  discussed  to  examine  similarities  and  differences  and  their 
application  to  WPC. 

C.  RESEARCH  QUESTIONS 

The  following  questions  will  be  addressed  within  this  paper: 

1 .  What  is  an  architecture  framework? 

2.  Why  is  an  architecture  framework  needed  for  a  DoD  project? 

3.  When  will  an  architecture  framework  be  used? 

4.  What  is  the  history  of  architecture  frameworks  in  DoD  projects? 
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5.  How  does  an  architecture  framework  assist  in  the  development  of  a  DoD 
project? 

6.  What  are  the  various  types  of  architecture  frameworks? 

7.  What  are  the  advantages  and  disadvantages  of  the  Zachman  framework? 

8.  What  are  the  best  and  worst  functions  of  the  Zachman  framework? 

9.  What  are  the  advantages  and  disadvantages  of  the  DoDAF? 

1 0.  What  are  the  best  and  worst  functions  of  DoDAF? 

1 1 .  Based  on  mission  need,  which  of  the  two  architecture  frameworks  should 
be  used  by  the  WPC’s  IPT? 

12.  How  effective  can  an  architecture  framework  be  in  the  development  of  a 
DoD  project? 

D.  BENEFITS  OF  STUDY 

This  study  will  provide  a  systems-based  analysis  of  two  architecture  frameworks 
to  aid  in  selection  of  one  framework  to  be  used  as  the  principle  framework  in  forming  the 
WPC’s  System  Architecture  Description  Document  (SADD).  The  recommendations  of 
this  study  can  be  applied  to  any  DoD  acquisition  project. 

E.  SCOPE  AND  METHODOLOGY 

1.  Scope 

This  thesis  will  be  limited  to  the  study  of  the  USCG  Deepwater  acquisition 
project  of  one  class  of  cutters  that  is  projected  to  have  a  littoral  mission  and  limited 
capabilities;  the  other  two  classes  of  USCG  cutters  will  have  a  deepwater,  naval-type 
mission  and  greater  capabilities.  A  recommendation  to  use  one  type  of  architecture 
framework  for  development  will  be  part  of  this  study. 

2.  Methodology 

The  methodology  used  in  this  thesis  research  consists  of  the  following  steps: 

Review  government  publications  that  describe  the  Department  of  Defense 
Architecture  Framework  and  its  use  in  project  development. 

Conduct  a  literature  review  of  books,  magazine  articles,  and  other  library 
information  resources  on  the  Department  of  Defense  Architecture  Framework  and 
Zachman  Architecture  Framework. 
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Conduct  a  thorough  review  of  previous  research  on  history,  comparison  and  use 
of  Architecture  Frameworks  in  DoD  projects. 

Conduct  a  review  of  current  capabilities  of  the  Department  of  Defense 
Architecture  Framework  and  compare  it  to  the  Zachman  Architecture  Framework. 

Create  a  demonstration  of  the  use  of  an  architectural  framework  on  a  DoD  project. 

Create  a  survey  to  gather  feedback  from  Technical  Directors,  Program  Managers, 
and  supervisors  about  the  use  of  architecture  frameworks  in  DoD  projects. 

Analyze  survey  feedback  and  make  recommendations  to  improve  selection  of 
architectural  frameworks. 

Establish  a  means  for  future  feedback  methods  involving  selection  of  architectural 
frameworks. 

F.  ORGANIZATION  OF  STUDY 

This  thesis  begins  with  an  introduction  that  briefly  states  the  background,  the 
purpose,  and  benefits  of  the  study  and  gives  an  idea  of  its  nature  by  means  of  a  listing  of 
the  research  questions  that  have  been  explored.  The  next  chapter  delves  into  the  two 
architecture  frameworks,  their  purpose,  history  and  capabilities.  The  third  chapter  deals 
with  the  initial  expectations,  pros  and  cons  of  the  two  architecture  frameworks.  This 
chapter  also  presents  a  comparison  of  the  two  architecture  frameworks  and  talks  of  the 
survey  and  its  development.  The  fourth  chapter  analyzes  the  results  from  the  survey  and 
presents  conclusions  about  architecture  framework  usage  in  the  DoD  workplace.  The 
fifth  chapter  describes  implementation  of  an  architecture  framework  for  the  System 
Architecture  Description  Document  of  the  WPC.  It  also  analyses  the  flaws  of  an 
architecture  framework  and  makes  recommendations  for  modifications  to  the  architecture 
framework.  Conclusions,  recommendations  and  areas  for  further  study  make  up  the  final 
chapter. 
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II.  LITERATURE  REVIEW 


A.  INTRODUCTION 

A  wealth  of  information  on  architecture  frameworks  and  their  application  can  be 
found  on  the  internet  and  in  many  books.  The  bulk  of  the  research  conducted  for  this 
thesis  came  from  sources  found  on  the  worldwide  web,  NPS  library  and  some  books. 

The  aim  of  this  thesis  is  to  compare  two  frameworks  (DoDAF  and  Zachman)  for 
usage  as  the  primary  architecture  framework  for  the  Systems  of  Systems  document  of  the 
USCG’s  WPC.  One  question  that  will  be  answered  in  this  thesis  is  “what  is  an 
‘Enterprise  Architecture  Framework’.”  Enterprise  is  defined  as  ‘a  project  or  undertaking 
that  is  especially  difficult,  complicated,  or  risky’.  Architecture  is  defined  as  ‘the  art  or 
science  of  building’.  Framework  is  defined  as  ‘a  basic  conceptional  structure  (as  of 
ideas)’. 

When  one  thinks  of  architecture,  buildings  and  the  plans  to  accomplish  their 
construction  come  to  mind.  From  the  smallest  house  to  the  tallest  building  in  the  world, 
all  must  have  plans  and  frameworks  to  accomplish  their  erection.  One  would  never  think 
of  trying  to  build  a  magnificent  skyscraper  without  detail  plans  and  engineering  efforts. 
From  the  pyramids  of  ancient  Egypt  to  the  Sears  Tower  in  Chicago,  massive  efforts  have 
been  spent  to  ensure  that  the  conceptional  structure  will  be  assembled  in  a  satisfactory 
manner.  Many  questions  have  to  be  answered  before  ground-breaking.  What  purpose 
will  the  building  serve?  Who  will  occupy  the  building  and  what  function  will  they  serve? 
Where  will  the  building  be  located  and  will  that  location  serve  the  purpose  of  the  users? 
Why  is  this  building  needed?  What  kind  of  forces  will  this  building  have  to  withstand? 
What  kind  of  materials  will  the  building  be  made  of?  What  finishes  are  needed?  How 
long  will  the  building  be  functional?  When  should  the  building  be  built  and  how  long 
will  it  take  to  build?  As  one  can  see,  many  questions  have  to  be  addressed  and  many 
detailed  plans  must  be  drawn  up  to  facilitate  the  construction  of  a  building. 

In  today’s  society,  because  of  the  size  of  the  populous  that  must  be  served, 
massive  and  complex  projects  have  been  undertaken  -  both  physical  and  informational. 
Because  of  the  complex  and  interrelated  nature  of  our  economy  and  various  other  entities 
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such  as  our  defense  forces,  we  must  ensure  that  all  of  our  capabilities  are  established  and 
recognized  and  that  future  growth  can  be  sustained.  To  successfully  complete  these 
efforts,  the  United  States  government  and  major  companies  alike,  have  developed  and 
employed  the  use  of  enterprise  architecture^  frameworks  which  can  be  described  as  a 
comprehensive  framework,  a  set  of  operational  guideline  and  rules  to  follow  to  manage 
and  align  an  organization’s  operations  and  projects  with  their  overall  strategy.  It  consists 
of  two  subsets:  Those  that  are  considered  as  basic  (compulsory)  and  those  which  are 
optional  and  may  add  value  or  efficiency  in  a  given  application.  The  architecture 
framework  should  be  able  to  be  modified  to  add  value  in  future  applications  based  on 
organizational  growth  and  needs. 

An  enterprise  architecture  framework  should  be  a  structured  process  that  helps 
guide  an  organization  to  make  sound,  targeted  decisions  about  how  to  manage  its 
information-related  assets  for  maximum  effectiveness.  Implementing  enterprise 
architecture  generally  starts  with  documenting  the  organization’s  strategy  and  other 
necessary  details  such  as  where  and  how  it  operates.  The  process  then  cascades  down  to 
documenting  discrete  core  competencies,  business  processes,  and  how  the  organization 
interacts  with  itself  and  with  external  parties  such  as  customers,  suppliers,  and  other 
entities.7  An  organization  should  be  able  to  use  an  enterprise  architecture  framework  to 
break  a  major,  complex  undertaking  into  many  manageable  bite-sized  pieces,  employ  a 
methodology  (or  science)  as  an  effort  for  accomplishment,  and  blend  those  efforts  into  a 
conceptional  structure  for  development. 

B.  DEPARTMENT  OF  DEFENSE  ARCHITECTURE  FRAMEWORK 

(DODAF) 

The  DoDAF  is  an  enterprise  architecture  framework  develop  by  the  Department 
of  Defense  (DoD)  C4ISR  (Command,  Control,  Communications,  Intelligence, 
Surveillance,  and  Reconnaissance)  Architecture  Working  Group  (AWG)  to  provide 
guidance  for  describing  architectures. 

1.  Purpose  of  DoDAF 

The  DoDAF  is  intended  to  ensure  that  architectures  developed  by  the  Commands, 
Services,  and  Defense  Agencies  are  interrelatable  between  and  among  the  organizations’ 
operational,  systems,  and  technical  architecture  views,  and  are  comparable  and 


8 


integratable  across  Joint  and  multi-national  organizational  boundaries.  The  framework  is 
intended  to  ensure  that  a  clear  audit  trail  exists  from  mission  operations  and  effectiveness 
measures  to  the  characteristics  of  current  and  postulated  C4ISR  systems  and  their 
contributions  (performance  and  interoperability  metrics)  to  mission  operations.8  The 
DoDAF  will  provide  guidance  for  describing  architectures  for  both  warfighting 
operations  and  business  operations  and  processes.  It  will  provide  the  guidance,  rules,  and 
product  descriptions  for  developing  and  presenting  architecture  descriptions  that  ensure  a 
common  denominator  for  understanding,  comparing,  and  integrating  Families  of  Systems 
(FOS),  Systems  of  Systems  (SOS),  and  interoperating  and  interacting  architectures.9  The 
extended  purpose  of  the  DoDAF  is  to  meet  DoD  policy  as  stated  by  John  P.  Stenbit, 
Department  of  Defense  Chief  Information  Officer,  in  his  February  9,  2004  memorandum 
authorizing  the  immediate  use  of  DoDAF  Version  1.0  ,  ‘Through  several  DoD  Directives 
and  related  issuances,  the  DoD  has  established  policy  and  procedures  that  direct  the  use 
of  integrated  architectures  to  support  Capital  Planning  and  Investment,  Joint  Capabilities 
Integration  and  Capabilities  System  (JCIDS),  the  Acquisition  System,  and 
interoperability  between  and  among  information  technology  (IT)  and  National  Security 
Systems  (NSS).  In  addition,  the  Information  Technology  Management  Reform  Act 
(ITMRA)/Clinger  Cohen  Act  (CCA)  of  1996  mandates  that  the  Chief  Information  Officer 
(CIO)  of  each  Executive  Agency  is  responsible  for  “developing,  maintaining,  and 
facilitating  the  implementation  of  a  sound  and  integrated  information  technology  for  the 
executive  agency.”10 

2.  History  of  DoDAF 

Historically,  Commands,  Services  and  Agencies  in  DoD  have  instituted 
architectures,  definitions,  techniques  and  presentation  schemes  to  suit  their  individual 
needs  in  deference  to  other  agencies.  However,  as  technology  advanced  and  DoD 
became  increasingly  aware  of  a  need  to  synthesize  on  the  joint  and  multinational  battle 
theater  as  spurred  by  Desert  Storm  and  other  major  conflicts,  DoD  sought  a  way  to 
standardize  architectures. 

In  October  1995,  the  Deputy  Secretary  of  Defense  directed  that  a  DoD-wide  effort 
be  undertaken  to  define  and  develop  better  means  and  processes  for  ensuring  that 
Command,  Control,  Communications,  Computers  and  Intelligence  capabilities  meet  the 
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needs  of  the  warfighter.  In  response  to  that  direction,  a  C4ISR  Integration  Task  Force 
(ITF)  was  established  under  the  direction  of  the  Assistant  Secretary  of  Defense  for 
Command,  Control,  Communications,  and  Intelligence  (ASD  [C3I]).  The  C4ISR 
Architecture  Framework,  Version  1.0,  dated  7  June  1996,  was  developed  as  a  product  of 
the  Integrated  Architectures  Panel  (IAP),  one  of  several  panels  established  by  the  ITF. 

In  October  1996,  the  ASD  (C3I)  and  Joint  Staff/J6  established  the  C4ISR 
Architecture  Working  Group  to  continue  the  effort  begun  by  the  IAP.  The  effort  resulted 
in  the  publication  of  the  C4ISR  Architecture  Framework;  Version  2.0  dated  18  December 
1997.  The  utility  of  the  C4ISR  Architecture  Framework,  combined  with  both  Federal 
and  DoD  policy  encouraging  the  use  of  architectures,  led  DoD  to  evolve  the  document 
into  the  DoDAF  in  2003. 11  This  evolution  was  accomplished  under  the  direction  of  the 
Architecture  Framework  Working  Group  (AFWG)  which  was  composed  of  Joint  Staff, 
Military  Services,  and  various  other  DoD  agencies  representatives. 

The  most  powerful  tool  used  by  the  legislative  and  executive  branches  of  the 
United  States  government  to  enact  information  technology  reform  was  the  Clinger-Cohen 
Act  (CCA).  In  1996,  recognizing  the  importance  of  information  technology  for  effective 
government,  the  Information  Technology  Management  Reform  Act  (ITMRA)  and  the 
Federal  Acquisition  Reform  Act  were  signed.  The  acts  became  known  as  the  (CCA)  and 
they  focused  on  the  need  for  Federal  Agencies  to  improve  the  way  they  select  and 
manage  information  technology  (IT)  resources.  The  CCA  states  “information  technology 
architecture,  with  respect  to  an  executive  agency,  means  an  integrated  framework  for 
evolving  or  maintaining  existing  information  technology  and  acquiring  new  information 
technology  to  achieve  the  agency’s  strategic  goals  and  information  resources 
management  goals”.  The  DoDAF  grew  out  of  this  and  related  policies  that  identified  the 

need  for  a  unified  architecture  framework  to  be  applied  during  the  development  of  those 
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architecture  descriptions  dictated  by  policy. 

3.  Capabilities  of  DoDAF 

The  Department  of  Defense  has  mandated  that  all  military  service  branches  use 
the  DoDAF  for  large-scale  software-intensive  systems.  This  framework  is  partitioned 
into  two  volumes  and  a  deskbook: 
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•  Volume  I  provides  definitions,  guidelines,  and  related  background 
material. 

•  Volume  II  contains  descriptions  for  each  product 

•  The  DoDAF  Deskbook  provides  supplementary  information  to  framework 
users. 

The  framework  provides  guidance,  rules,  and  product  descriptions  for  developing 
and  presenting  architecture  descriptions.  An  architecture  description  is  a  representation 
of  a  defined  domain,  as  of  a  current  or  future  point  in  time,  in  terms  of  its  component 
parts,  what  those  parts  do,  how  the  parts  relate  to  each  other,  and  the  rules  and  constraints 
under  which  the  parts  function.  It  will  also  describe  how  the  architecture  for  a  system  or 
system  of  systems  (SoS)  should  be  documented. 

In  the  framework,  there  are  three  major  perspectives  that  logically  combine  to 
describe  an  architecture  description  and  each  view  depicts  certain  architecture  attributes. 
They  are  Operational  View  (OV),  System  View  (SV),  and  Technical  View  (TV).  Each  of 
the  three  views  depicts  certain  architecture  attributes.  Some  attributes  bridge  two  views 
and  provide  integrity,  coherence,  and  consistency  to  architecture  descriptions.13  The 
operational  view  (OV)  consists  of  9  products;  the  system  view  (SV)  consists  of  13 
products;  and  the  technical  view  (TV)  consists  of  2  products.  An  additional  all  view 
(AV)  consists  of  two  products,  one  of  which  is  a  graphic  showing  the  weapons  platforms 
involved,  and  the  other  is  a  data  dictionary  containing  the  data  items  defined  in  the  OV, 
SV,  and  TV  products.14 

Architecture  products  are  those  graphical,  textual,  and  tabular  items  that  are 

developed  in  the  course  of  building  a  given  architecture  description  and  that  describe 

characteristics  pertinent  to  the  purpose  of  the  architecture.  When  used  as  a  part  of  an 

architecture  description,  all  products,  even  those  whose  primary  presentation  is  graphical, 

should  contain  explanatory  text.15  Individual  products  are  not  stand-alone  entities  but 

represent  depictions  of  subsets  of  architecture  data  describing  various  aspects  of 

architecture.  Therefore,  relationships  exist  among  the  architecture  data  elements  that 

compose  the  various  products,  creating  relationships  among  the  products.  Figure  2 

illustrates  some  of  the  major  relationships  among  selected  products.16  A  list  of  all  the 
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products  is  contained  in  Table  1  in  Appendix  A.  An  in-depth  description  of  each  product 
and  the  relationships  among  products  are  discussed  in  detail  in  Volume  II  of  the  DoDAF. 
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Figure  1.  Relationships  among  products 


The  OV  describes  the  activities,  operational  elements,  and  information  flows 
required  for  a  number  of  missions  supported  by  the  SoS.  This  information  is  described  in 
terms  of  the  mission’s  nodes,  the  operational  activities  conducted  within  these  nodes,  and 
the  needlines  connecting  the  intemodal  activities.  A  node  often  means  a  mobile  weapons 
platform  (e.g.,  a  ship,  tank,  or  aircraft)  or  a  fixed  ground  platform  (e.g.,  a  command  and 
control  center,  or  a  communication  hub).  An  operational  activity  is  usually  associated 
with  a  warfighter  and  consists  of  a  combination  of  manual  and  automated  actions  taken 
by  the  warfighter,  such  as  tactical  planning  and  engagement  of  an  enemy  platform.  A 
needline  is  a  description  of  the  information  that  moves  from  one  activity  to  another,  such 
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as  a  tactical  plan,  by  some  automated  or  manual  route. 

The  SV  describes  the  system-level  structures  that  support  the  OV’s.  The  SV 
includes  the  systems  required  at  each  node,  the  communication  media  connecting  the 
nodes,  and  the  functions  contained  within  each  system.  In  addition,  this  view  contains 

tables  describing  how  each  needline  listed  in  the  OV  products  is  implemented  by  the 
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communication  media  listed  in  the  SV  products  and  tables.  These  tables  show  how  each 
activity  described  in  the  OV  products  maps  onto  the  functions  described  in  the  SV 
products.18 

The  TV  describes  the  minimal  set  of  rules  governing  the  arrangements, 
interactions,  and  dependencies  of  system  components.  This  view  includes  standards  used 
in  the  SoS,  and  the  commercial  off  the  shelf  (COTS)  and  GOTS  components  used.19 

A  fourth  set  of  products,  the  AV,  includes  two  products  that  provide  an  overview 
perspective  of  the  entire  system.  Figure  2  illustrates  the  relationships  among  the  three 
primary  views  of  the  architecture  framework. 


Operational 

View 


Figure  2.  DoD  Views’  relationships 


The  high-level  operational  concept  should  drive  the  OV.  The  OV  in  turn  drives 
the  SV  to  identify  shortfalls  and  systems  requirements  drive  the  TV  to  address  a  common 
set  of  applicable  standards.  To  be  internally  consistent  and  integrated,  an  architecture 
description  must  provide  explicit  linkages  among  its  various  views.  Figure  2  illustrates 
the  primary  linkages  among  the  three  views.  In  Figure  2,  the  OV  describes  the  nature  of 
each  information  exchange  in  detail  sufficient  to  determine  the  degree  of  operational 
interoperability  required.  The  SV  identifies  which  systems  support  the  operational 
requirements,  translates  the  required  degree  of  interoperability  into  a  set  of  system  data 
exchanges  executed  by  system  functions,  and  compares  current/postulated 
implementations  with  the  required  operational  capabilities.  The  TV  articulates  the 
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criteria  that  govern  the  compliant  implementation  of  each  required  system  that  will  result 
in  the  fielding  of  an  interoperable  system.  Thus,  the  three  views  and  their 
interrelationships  provide  the  basis  for  deriving  measures  such  as  interoperability  or 

performance  and  also  provide  the  basis  for  measuring  the  impact  of  the  values  of  these 
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metrics  on  operational  mission  and  task  effectiveness. 

4.  Summary 

The  DoDAF  provides  a  common  approach  for  developing  architecture 
descriptions  and  a  basic  foundation  for  relating  architectures.  The  framework  is  intended 
to  ensure  that  architecture  descriptions  can  be  compared  and  related  across  organizational 
boundaries,  including  Joint  and  multinational  boundaries.  The  framework  also  provides 
a  critical  mechanism  for  understanding  operational  concepts  and  their  relation  to 

capabilities,  anticipating  changes  in  operational  concepts  or  changes  in  automated 
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capabilities,  and  acquiring  both  material  and  non-material  assets. 

The  DoDAF  has  a  set  of  guiding  principles,  compliance  guidelines  and  a  generic 
process  for  developing  an  architecture  description  as  shown  in  Figure  3.  This  process 
must  be  adapted  to  an  individual  business  needs  or  tailored  to  the  needs  of  the  particular 
organization.  It  is  intended  to  provide  guidance  for  the  architect  who  is  applying  the 
framework. 
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Figure  3.  Determining  Use  of  Architecture 


The  capabilities  of  the  DoDAF  are  vast  in  that  it  provides  common  language  and 
structure,  the  ability  to  have  an  integrated  and  interacting  architecture  for  DoD  platforms 
and  creates  a  functional  development  process  for  those  architectures,  and  provides 
architecture  focus  for  the  development  of  software  intensive  products 
C.  ZACHMAN  FRAMEWORK  (ZF) 

The  Zachman  architecture  framework  was  developed  by  John  Zachman  for  use  by 
organizations  as  they  embarked  upon  various  enterprises.  It  serves  as  an  organizational 
tool  in  developmental  efforts. 

1.  Purpose  of  ZF 

In  1987,  John  Zachman,  wrote:  “To  keep  the  business  from  disintegrating,  the 
concept  of  information  systems  architecture  is  becoming  less  of  an  option  and  more  of  a 
necessity.”  From  then  on,  the  enterprise  architecture  framework  of  Zachman  has  evolved 
and  become  the  model  around  which  many  major  organizations  view  and  communicate 
their  enterprise  information  infrastructure.  It  provides  a  blueprint,  or  architecture,  for  the 
organization’s  current  and  future  information  infrastructure.23 
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In  his  white  paper  “A  Disciplined  Approach  to  Managing  Enterprise  Information 
Systems  Architectures”,  Robert  W.  Ridlon,  Jr.  submits  the  following  abstract: 
Organizations,  in  both  the  public  and  private  sectors,  are  undergoing  relentless  change. 
They  face  the  inevitability  of  environmental  change,  politically,  technologically,  and 
economically.  This  dynamic  environment  has  brought  with  it  a  demand  for  the  right 
information  as  a  critical  resource  for  organizational  success.  It  is  not  merely  the 
availability  of  information,  but  more  importantly  the  quality  of  information.  In  addition 
to  the  information,  the  technology  for  managing  it  also  continues  to  change.  In  our 
dynamic  environment,  missions  change,  strategic  plans  follow,  and  new  organizational 
goals  and  objectives  are  set.  This  changes  the  needs  of  the  decision-makers  and  front  - 
line  users  of  information.  As  their  information  needs  change,  there  must  be  a  mechanism 
for  effectively  and  efficiently  identifying  these  needs  and  once  identified,  translate  them 
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into  a  solution  that  is  accepted  by  the  information  user. 

2.  History  of  ZF 

John  Zachman  worked  in  the  information  strategy  community  in  the  late  1960’s 
and  early  1970’s  and  noticed  that  in  project  after  project  his  team  was  having  problems 
getting  from  strategy,  which  they  understood  well,  to  implementation,  which  his  team  did 
not  understand.  He  felt  that  information  strategy  groups  needed  a  way  to  bridge  the  gap 
between  strategy  and  implementation  and  establish  an  environment  that  was  conducive  to 
change  with  the  upgrade  in  technology. 

In  1972,  Zachman  moved  to  the  Los  Angeles  area,  where  he  began  to  do 
information  strategy  work  for  air-frame  manufacturing  companies.  He  and  others  in  his 
industry  were  struck  by  the  fact  that  the  enterprise  systems  they  were  attempting  to  build 
and  implement  were  strikingly  similar  to  the  manufacturing  of  airplanes  -  both  were 
complex  exercises  of  product  development  and  manufacturing  processes.  However,  the 
airplane  manufacturers  had  figured  out  the  architecture  of  airplanes  and  what  it  took  to 
move  from  strategy  to  implementation.  They  were  able  to  produce  a  produce  a  product 
that:  1)  Was  relevant  to  the  marketplace;  2)  was  able  to  be  assembled  piece  by  piece,  unit 
by  unit ,  sub-assembly  by  sub-assembly;  and  3)  maintainable  over  time  in  the  face  of  a 
changing  marketplace  and  technology,  with  little  obsolescence. 
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The  problems  faced  by  Zachman  and  others  working  in  the  information  strategy 
field  were  that  their  product  (system)  was  not  relevant  to  the  marketplace  (enterprise)  in 
its  final  form,  and  if  not  relevant  at  the  time  of  marketplace  entrance,  it  had  no  life  cycle 
to  be  concerned  with.  Zachman’s  dilemma  was  to  discover  or  construct  an  architecture 
that  would  provide  for  the  meeting  of  the  three  constraints  mentioned  above:  1) 
Relevance  to  the  marketplace;  2)  ability  to  be  readily  assembled;  and  3)  maintainable  and 
able  to  be  upgraded  over  time. 

John  Zachman  learned,  not  only  from  engineering  and  manufacturing,  but  from 
other  ‘old  world’  trades  such  as  architecture  and  construction  where  the  conceptual 
structures  are  identical.  He  discovered  that  while  there  is  not  a  simple  architectural 
representation  for  a  complex  product,  there  is  a  set  of  representations  of  a  complex 
product.  There  are  representations  from  different  perspectives,  or  roles,  being  played  in 
the  process  of  producing  the  product.  For  example,  there  are  representations  of  the  end 
product  from  the  perspective  of  the  customer,  or  ultimate  ‘owner;’  from  the  perspective 
of  the  engineer,  or  ‘designer;’  and,  from  the  perspective  of  the  manufacturing  engineer,  or 
‘builder’  of  the  product;  along  with  some  other  perspectives.  There  are  also  intersecting 
representations  of  the  different  characteristics  of  the  product.  For  example,  there  are 
representations  of  the  material  composition  of  the  product  from  the  perspective  of  the 
builder,  etc.  Likewise,  there  are  intersecting  representations  of  the  function  and  geometry 
of  the  product  from  the  perspectives  of  the  owner,  designer  and  builder. 

However,  in  John  Zachman’s  words  the  breakthrough  realization  was  that  the 
representations  of  the  intersecting  characteristics,  that  is  ‘material,’  ‘function,’  and 
‘geometry,’  were  actually  descriptions  of  WHAT  the  product  was  made  of,  HOW  the 
product  worked  and  WHERE  the  components  were  located  relative  to  one  another.  From 
that  observation,  it  was  obvious  that  a  comprehensive  description  of  WHO  does  what 
relative  to  the  product,  WHEN  do  things  happen  and  WHY  are  various  product  choices 
being  made.  This  resulted  in  Zachman  building  and  publishing  (in  1987)  the  enterprise 
framework  that  bears  his  name  (Figure  4). 
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THE  ZACHMAN  FRAMEWORK  FOR  ENTERPRISE  ARCHITECTURE 


Figure  4.  Zachman  Framework 


3.  Capabilities  of  ZAF 

Many  books  have  been  written  to  establish  why  the  ZAF  was  written  and  even 
more  books  have  been  written  on  its  usage.  Some  of  those  authors  have  worked  in 
tandem  with  Zachman,  but  more  have  not,  so  some  of  the  interpretations  are  of  a 
significance  value  because  they  are  written  from  the  perspective  of  direct  application. 
This  thesis  will  examine  what  John  Zachman,  the  author  of  the  ZAF,  gives  as  capabilities 
and  what  others  see  as  capabilities  of  the  ZAF. 

The  framework  is  a  schema  for  classifying  and  organizing  the  topics  related  to 
managing  the  enterprise,  as  well  as  to  the  design,  development,  and  manifestation  of  the 
enterprise.  The  framework  is  also  a  classification  schema  for  organizing  descriptive 
representations  (artifacts)  of  an  enterprise.  Through  this  classification  and  organization 
of  topics,  the  framework  can  assist  the  organization  in  becoming  more  accountable  and 
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responsive.27  The  organization  can  be  a  variety  of  enterprises  such  as  a  business, 
governmental  agency,  family  or  an  individual.  In  the  fast  paced,  changing  environment 
in  all  sectors  and  domains,  one  must  successfully  adapt  and  this  requires  integration, 

alignment  and  responsiveness.  The  Zachman  framework  helps  pull  together  people  and 
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technology  to  create  a  successful,  competitive  enterprise. 

Figure  4  shows  the  Zachman  framework  for  an  enterprise  architecture.  The 
framework  describes  a  holistic  model  of  an  enterprise’s  information  infrastructure  from 
six  perspectives:  planner,  owner,  designer,  builder,  subcontractor,  and  the  working 
system  or  functioning  enterprise  and  six  aspects:  who,  what,  when,  where,  how  and 
why.  The  perspectives  represent  viewpoints  whereas  the  aspects  represent  subject  areas. 
The  framework  tells  a  story  of  completeness  because  its  six  perspectives  and  six  aspects 
form  a  holistic  representation  of  the  enterprise.30  The  framework  contains  six  rows  and 
six  columns  and  at  the  intersection  of  each  row  and  column  is  a  cell  for  a  total  of  36  cells. 
Each  cell  represents  a  fundamental  piece  of  knowledge  relative  to  the  row  and  column 
and  is  known  as  a  primitive.  Having  complete  knowledge  of  each  primitive  is  relative  to 
understanding  the  functioning  enterprise.  A  comprehensive  knowledge  base  (knowledge 
of  all  the  primitives)  helps  one  to  understand  and  determine  whether  the  functioning 
enterprise  is  working  appropriately.  An  appropriately  functioning  enterprise  is  one  that  is 
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aligned,  flexible,  integrated,  and  responsive. 

Although  the  framework  is  intended  to  be  generic,  it  follows  a  good  software 
pattern  by  listing  each  cell  with  a  descriptive  template.  Each  cell  in  the  framework  is 
illustrated  with  a  sample  icon,  an  appropriate  primitive  model  description,  and  a  primitive 
component.  Figure  5  shows  a  sample  icon. 
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Figure  5.  Graphical  display  of  cell 


Each  cell  is  the  intersection  of  a  perspective  (constraint)  and  an  aspect  (variable)  - 
the  rows  and  columns,  respectively,  of  the  framework.  The  framework  hieroglyphic 
implies  that  if  knowledge  from  each  cell  is  made  explicit,  the  functioning  enterprise  will 
be: 


•  Operational 

•  Aligned  to  each  part  of  the  enterprise 

•  Flexible 

•  Adaptable 

•  Able  to  embrace  change 
a.  Perspectives 

There  are  six  perspectives  in  the  framework  and  they  can  be  classified  as: 

•  Principal 

•  Empirical 

•  Certifiable 
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The  principle  perspectives  of  the  framework  are  the  owner,  designer  and 
builder  (rows  2,  3  and  4)  because  these  are  the  primary  perspectives  of  architectural 
design.  Each  perspective  is  contextual  in  that  the  problem  area  is  viewed  as  a  whole. 
Needing  to  view  the  entire  problem  area  holistically  is  a  trait  of  the  principal 
perspectives.33 

The  owner’s  perspective  is  identified  as  row  2  of  the  framework.  He/she 
is  often  the  intended  recipient  of  the  final  product  or  service  and  the  artifacts  produced 
represent  the  desirable  characteristics  of  the  product  or  service  and  the  artifacts  show 
what  the  owner  is  going  to  do  with  the  product  or  service.  The  owner’s  perspective  is  a 
conceptual  view  of  the  final  product  or  service.34 

The  designer’s  perspective  is  identified  as  row  3  of  the  framework.  The 
designer  is  the  engineer  or  architect  of  the  final  product  or  service  and  he/she  is  the 
intermediary  between  the  owner  and  builder.  The  artifacts  produced  by  the  designer 
represent  the  laws  of  nature,  the  system  or  the  logical  constraints  of  the  product’s  or 
service’s  design.  The  designer  has  a  logical  view  of  the  final  product  or  service.35 

The  builder’s  perspective  is  identified  as  row  4  of  the  framework.  The 
builder  is  the  manufacturing  engineer  or  general  contractor  of  the  final  product  or  service. 
The  builder  applies  the  physical  constraints  of  what  is  possible  to  the  designer’s  artifacts 
-  he/she  understands  how  the  product  can  be  built  and  used.  The  builder’s  perspective  is 
a  physical  view  of  the  final  product  or  service. 

The  empirical  perspectives  of  the  framework  are  the  planner  and 
subcontractor  (rows  1  and  5).  The  planner’s  perspective  is  contextual  regarding  the 
problem  area,  however  the  subcontractor’s  view  is  non-contextual  in  that  his/her  artifact 
depict  the  product  disassembled  into  parts,  so  that  the  product  or  service  can  be 
manufactured  piece  by  piece  and  then  assembled  into  the  final  product.36 

The  planner’s  perspective  is  identified  as  row  1  of  the  framework.  The 
planner  provides  scope  for  the  enterprise  in  that  he/she  establishes  the  context  for  the 
enterprise,  inner  and  outer  limits  and  the  list  of  relevant  constituents  which  must  be 
accounted  for  in  the  artifacts  of  the  other  perspectives. 


21 


The  subcontractor’s  perspective  is  identified  by  row  5  of  the  framework. 
He/she  creates  the  detailed  descriptions  that  disassociate  the  parts  or  pieces  of  the 
complex  object  for  purposes  of  manufacturing.  The  subcontractor  is  out  of  context  and 
seeks  to  fabricate  and  assemble  all  the  necessary  components.37 

The  certification  perspective  is  the  functioning  enterprise  and  there  is  no 
artifact  representation  because  the  functioning  enterprise  is  the  culmination  of  the  other 
perspectives  and  is  the  real  thing. 

The  functioning  enterprise  perspective  is  identified  by  row  6  of  the 
framework.  The  functioning  enterprise  is  the  physical  materialization  of  the  product  or 
service  and  is  the  result  of  what  is  articulated  through  artifacts.  Certification  is  a  formal 
declaration  from  the  designer,  builder,  and  subcontractor  to  the  owner  that  the 
functioning  enterprise  is  as  the  owner  described.38  Therefore,  row  6  represents  the 
functioning  product,  goods  or  services  and  what  the  users  will  experience. 

b.  Aspects 

The  framework’s  viewpoints  or  perspectives  are  represented  horizontally 
as  rows,  whereas  the  framework’s  subject  areas  or  aspects  are  represented  vertically  as 
columns.  The  framework’s  aspects  are  based  solely  on  the  six  primary  interrogatives  of 
the  English  language:  what,  how,  where,  who,  when  and  why  because  they  can  answer 
or  address  all  questions.39  This  approach  normalizes  the  framework  and  reduces  facts 
and  questions  to  one  location  within  the  framework,  which  makes  it  (the  framework)  an 
effective  communication  vehicle. 

The  six  aspects  of  the  framework  -  what,  how,  where,  who,  when,  and 
why  -  represent  the  independent  variables  in  a  complete,  normalized  domain: 

•  What  -  is  it  made  of? 

•  How  -  does  it  work? 

•  Where  -  are  the  components  located? 

•  Who  -  performs  what  functions? 

•  When  -  does  something  happen? 
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•  Why  -  do  things  happen? 

The  framework’s  aspects  indicate  the  primitive  units  of  measure  for 
evaluating  an  enterprise  in  action.  The  six  units  of  measure  are  inventory,  yield,  capacity, 
performance,  duration  and  state: 

•  What  -  inventory  -  for  the  things  of  interest 

•  How  -  yield  -  for  each  process 

•  Where  -  capacity  -  for  each  node 

•  Who  -  performance  -  for  each  work  function 

•  When  -  duration  -  for  the  response  time  and  cycles 

•  Why  -  state  -  for  desire  and  is  associated  with  quality40 

John  Zachman  has  repeatedly  stated  that  the  columns  of  his  framework 
have  no  particular  order,  but  for  simplicity  sake  this  study  will  assume  order.  The 
columns  of  the  framework  represent  the  six  interrogatives  of  the  English  language:  what, 
how,  where,  who,  when  and  why. 

What  is  the  first  column  of  the  framework  and  denotes  the  material 
composition  of  the  enterprise.41  This  column  is  a  centerpiece  for  all  relationships 
throughout  the  enterprise  and  identifies  the  things  that  matter. 

How  is  the  second  column  of  the  framework  and  denotes  the 
transformations  caused  by  the  processes  of  the  enterprise.  A  transformation  is  an  input  to 
a  process  that  is  altered  in  some  way  to  form  an  output  -  process  begets  process.42 

Where  is  the  third  column  of  the  framework  and  denotes  the  connectivity 
between  the  enterprise’s  node  points.43  This  column  often  forms  the  geometry  of  the 
enterprise  and  is  of  importance  to  the  owner  and  planner  because  it  serves  as  a  conduit  to 
distribute  goods  and  services. 

Who  is  the  fourth  column  of  the  framework  and  denotes  the  collaboration, 
responsibility,  or  workflow  of  the  organization  and  its  people.  The  focuses  of  this  aspect 
are  performance,  worker  interactions  and  security.44 
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When  is  the  fifth  column  of  the  framework  and  denotes  the  dynamics  and 
timing  of  the  enterprise.  This  aspect  focuses  on  the  triggers  that  cause  events  in  the 
enterprise  and  the  schedule  that  handles  each  type  of  event.45 

Why  is  the  sixth  column  of  the  framework  and  denotes  the  strategy,  plans, 
direction,  values  and  guidance.  The  focus  of  this  aspect  is  the  motivation  for  the  purpose 
and  survival  of  the  enterprise.46 

c.  Cells 

The  intersection  of  a  single  row  and  a  single  column  is  represented  by  a 
primitive  cell  that  represents  an  artifact  because  it  is  from  a  single  constraint  (the 
perspective)  and  a  single  variable  (the  aspect).  A  model  is  a  typical  artifact  used  for 
representing  the  contents  of  a  cell  for  any  domain.  A  model  based  on  a  single  cell  is  a 
primitive  model.  The  contents  of  a  primitive  model  are  a  series  of  primitive 
components.  Primitive  models  are  the  basis  for  producing  enterprise  architectures.  If 
the  enterprise  is  not  described  using  primitive  components  and  primitive  models,  then 
the  architecture  is  being  compromised  47 

Each  cell  has  two  dimensions:  scope  and  detail.  Scope  is  the  complete 
outlook  of  the  artifact  and  detail  is  the  level  of  description  contained  in  the  artifact. 
When  everything  about  a  primitive  has  been  recorded  in  an  artifact,  the  artifact  has 
reached  a  level  of  excruciating  detail  which  is  the  contents  of  the  artifact  being  complete 
in  all  respects.  The  artifacts  of  a  cell  can  include  high-level,  mid-level  and  low-level 
views,  all  of  which  serve  to  describe  the  scope  and  detail  dimensions  at  various  stages. 

The  framework’s  cells  do  not  build  upon  each  other;  rather  they  are 
primitive  models  which  have  characteristics  of  scope  and  detail  that  defines  its  artifact. 
Each  cell  is  independent  of  each  other.  Each  cell  can  be  integrated  with  every  other  cell 
in  the  same  row  and  transformation  occurs  vertically  between  rows.  Navigation  between 
cells  occurs  vertically  up  or  down  a  column  or  horizontally  along  a  row  but  not 
diagonally  between  rows. 

The  principle  of  reusing  components  in  an  enterprise  is  a  desirable 
attribute  and  the  primitive  nature  of  each  cell  in  the  framework  lends  itself  to  producing 
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normalized  and  standard  interchangeable  parts.  Each  cell  in  the  framework  has  scoped 
and  detailed  artifacts  and  components  that  are  engineered  from  the  details  in  each  cell  are 
built  for  reuse. 

4.  Summary 

The  Zachman  framework  is  a  writing  system,  a  planning  tool,  and  a  problem¬ 
solving  tool.  Its  characteristics  can  be  summarized  as  follows: 

•  Simple  to  use 

•  Comprehensive  in  structure 

•  Neutral  to  method  of  practice  and  technology 

48 

•  Ubiquitous 

The  framework  is  a  writing  system  because  it  allows  architects  to  use  common 
language  as  opposed  to  technical  language  in  their  planning  efforts. 

The  framework  is  a  planning  tool  because  it  presents  architects  with  a  holistic 
view  of  an  enterprise  which  improves  decision  making. 

The  framework  is  a  problem-solving  tool  because  it  allows  architects  to  focus  on 
one  aspect  of  the  enterprise  without  losing  focus  on  the  complexity  of  the  entire 
enterprise. 

The  framework  is  simple  to  use  because  it  is  based  on  logic  rather  than  a  specific 
method,  technology  or  a  need.  It  sums  up  an  enterprise  in  its  entirety  and  is 
comprehensive  in  scope  and  detail.  All  specific  issues  of  an  enterprise  can  be  mapped  to 
a  particular  cell  of  the  framework  to  see  how  it  fits  in  the  overall  context  of  the  enterprise. 

The  framework  is  comprehensive  in  structure  because  it  presents  a  holistic  view 
of  an  enterprise  by  presenting  six  perspectives  (rows)  and  six  aspects  (columns)  and  their 
intersections  (36  individual  cells)  which  are  primitive  models,  which  comprise  primitive 
composites  which  describe  the  enterprise  in  detail. 

The  framework  is  independent  of  method,  technology  or  need.  It  can  be  applied 
to  any  decision  making  enterprise. 


25 


The  framework  is  ubiquitous  in  that  it  is  not  limited  to  information  technology  or 
business.  Its  principles  can  be  applied  to  family  matters,  education,  laboratory  work  or 
any  other  enterprise  requiring  planning  and  decision  making. 
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III.  RESEARCH  METHODOLOGY 


A.  INTRODUCTION 

When  one  begins  a  project,  he/she  must  begin  with  a  set  of  expectations, 
directions,  and  limitations  which  will  serve  to  lead  to  the  completion  of  the  project.  This 
thesis  did  not  consider  various  frameworks  such  as  the  TOGAF  or  DoD  Enterprise 
Architecture  2  Business  Reference  Model  for  use  as  the  architecture  for  the  WPC’s 
system  of  systems  document  because  their  application  would  not  be  in  line  with  the 
direction  of  this  study.  This  thesis  researches  and  compares  the  DoDAF  and  Zachman 
framework  for  use  as  the  architecture  framework  for  the  system  of  systems  document  for 
the  USCG’s  WPC. 

B.  RESEARCHING  DODAF 

1.  Initial  Expectations 

When  studying  a  complex  document  that  is  designed  to  be  a  working  framework 
for  the  development  of  an  enterprise,  it  is  expected  that  the  document  will  yield  criteria  of 
high  grade  quality.  In  the  case  of  the  DoDAF,  it  was  expected  to  be  simplistic,  logical, 
comprehensive  and  structural  in  its  capabilities  to  define,  integrate  and  manage  the 
development  of  software-intensive  systems  for  usage  by  the  United  States  military. 

The  DoDAF  is  simplistic  in  that  it  breaks  down  a  complex  structure  into  three 
simple  views:  The  Operations  View  (OV),  the  System  View  (SV)  and  the  Technical 
View  (TV).  Each  view  is  further  broken  down  into  sub-views  or  framework  products: 
OV  has  9  sub- views;  SV  has  13  sub- views  and  the  TV  has  2  sub-views.  Each  sub-view  is 
an  architecture  product  which  is  used  to  develop  an  architecture  description. 

The  DoDAF  is  logical  in  that  it  guides  the  architect  or  architecture  team  to  the 
completion  of  an  integrated  process.  Each  product  describes  a  function  which  must  be 
completed  to  establish  the  enterprise.  The  OV  has  5  products  whose  usage  is  mandatory, 
while  the  SV  has  9  products  whose  usage  is  mandatory  and  both  Technical  Views  are  to 
be  used  in  all  situations.  The  DoDAF  also  has  two  All  Views  (AV)  products  which 
contain  the  scope,  purpose  and  Integrated  Dictionary  of  the  entire  project. 
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The  DoDAF  is  comprehensive  in  that  it  defines  the  enterprise  in  totality,  from 
conception  to  design  to  implementation  through  verification  and  validation,  through 
upgrades  and  final  disposal.  The  framework  stimulates  the  architect  to  produce  a  product 
that  can  grow  as  the  product  grows  and  be  upgraded  as  technology  changes  and  software 
requirements  migrate. 

The  DoDAF  is  highly  structural  in  that  it  provides  a  sturdy  framework  or  base 
from  which  to  begin  building  an  architecture  description.  The  three  views  (Figure  2): 
OV,  SV  and  TV  are  interrelated  and  have  a  degree  of  interoperability  so  that  their 
combined  composition  forms  a  firm  base  from  which  the  entire  enterprise  structure  can 
be  built.  The  high-level  operational  concept  drives  the  OV  and  the  OV  drives  the  SV  to 
identify  shortfalls  and  systems  requirements.  The  SV  requirements  drive  the  TV  to 
address  a  common  set  of  applicable  standards.49  This  describes  part  of  the  fundamental 
linkages  among  the  views. 

The  DoDAF  is  a  framework  tool  used  to  integrate  various  architecture  products 
into  an  architecture  description.  After  studying  the  various  aspects  of  the  DoDAF,  the 
initial  expectations  of  the  user  to  be  able  to  apply  the  framework  simplistically,  in  a 
logical  manner,  comprehensively  and  structurally  can  be  met. 

2.  Initial  Pros 

The  proficiencies  of  the  DoDAF  are  too  numerous  and  making  a  comprehensive 
list  of  all  of  them  is  not  within  the  scope  of  this  document.  However,  some  of  the  initial 
pros  of  the  DoDAF  are  that  it  is  organizational,  informational,  and  is  a  networking 
document. 

The  DoDAF  is  organizational  in  that  it  provides  structure  throughout  the  entire 
document.  The  framework  provides  a  working,  upgradeable  product  that  can  be  used  to 
efficiently  and  effectively  manage  a  software-intensive  project  from  its  inception  to  its 
disposal.  It  is  a  combination  of  three  major  views  which  are  interoperable  and 
interrelated.  Each  of  those  views  is  further  divided  into  products  -  some  of  which  are  of 
higher  detail  than  other  products.  The  architect  using  the  framework  is  given  guidance  in 
how  to  move  from  one  product  to  another.  Each  product  is  specified  in  terms  of 
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templates  and  information  to  capture  in  each  product  and  the  integration  of  the  individual 
products  make  up  an  architecture  description. 

The  DoDAF  is  informational  in  that  it  provides  specific  instructions  and  guidance 
on  its  usage.  The  framework  is  partitioned  into  two  volumes  and  a  deskbook: 

•  Volume  I  provides  definitions,  guidelines,  and  related  background 
material. 

•  Volume  II  contains  descriptions  for  each  product. 

•  The  DoDAF  Deskbook  provides  supplementary  information  to  framework 
users. 

The  framework  also  provides  instructions  on  how  to  develop  and  determine  the 
use  the  architecture  (Figure  3).  In  its  informational  effort,  the  framework  dedicates  an 
entire  volume  to  the  description  of  architecture  products  and  their  usage  in  the 
development  of  an  architecture  description. 

The  DoDAF  is  networking  at  its  core.  The  OV,  SV  and  TV  views  are  networked 
together  to  achieve  a  firm  base  for  the  growth  of  an  enterprise.  The  framework  provides 
a  network  such  that  the  architecture  description  developed  by  its  guidance  will  integrate 
with  other  architectures  developed  by  its  guidance.  The  capabilities  of  DoD  to  perform 
Net-Centric  Operations  and  Warfare  are  further  enhanced  by  the  networking  aspects  of 
the  framework.  The  DoD  must  have  the  ability  to  portray  and  understand  complex  many- 
to-many  relationships  and  to  achieve  that,  the  architects  of  various  military  Net-Centric 
systems  employ  the  DoDAF  because  of  its  ability  to  portray  a  holistic  view  of  a  system 
while  integrating  the  products  that  describe  the  system.  The  OV,  SV  and  TV  views  have 
24  products  that  are  networked  together  to  form  an  architecture  description. 

3.  Initial  Cons 

The  DoDAF,  like  all  other  products  used  for  enterprise  architecture,  has 
drawbacks,  hurdles,  shortcomings  and  disadvantages.  Some  of  those  consequences  are 
based  on  the  fact  that  different  projects  demand  different  approaches  and  they  require 
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different  outcomes.  However,  some  of  those  consequences  reside  within  the  document 
itself.  Some  of  the  initial  cons  of  the  DoDAF  are  that  it  is  cumbersome,  inelastic,  and 
unalterable. 

The  DoDAF  is  cumbersome  in  that  it  is  a  huge  document.  The  framework  is 
divided  into  two  massive  volumes  and  a  deskbook.  Volume  I  provide  definitions  and 
guidelines  for  its  usage.  Volume  II  contains  ponderous  descriptions  for  each  of  the  26 
products  contained  within  four  views:  the  AV,  OV,  SV  and  TV.  The  deskbook  provides 
supplementary  information  to  framework  users.  An  inexperienced  or  beginning  architect 
can  be  overwhelmed  by  the  tremendous  amount  of  information  that  is  found  in  the 
DoDAF.  It  is  not  unlike  many  other  DoD  products  that  are  overwhelmingly  wordy  and 
over-illustrated. 

The  DoDAF  is  inelastic  in  that  it  follows  a  direct  path  with  little  variance.  Within 
its  product  descriptions,  the  framework  leaves  little  room  for  tolerances  or  diversions 
from  its  intended  results.  The  development  of  architecture  products  is  micromanaged 
throughout  the  framework.  Each  product  description  has  a  product  definition,  product 
purpose,  product  detailed  description,  UML  representation,  data  element  definition,  and  a 
Core  Architecture  Data  Model  (CADM)  support  paragraph.  While  this  is  not  inherently 
bad,  it  is  an  example  of  the  inelasticity  of  the  framework. 

The  DoDAF  is  unalterable  in  that  it  takes  an  act  of  Congress  to  initiate  changes. 
The  Clinger-Cohen  Act  of  1996  focused  the  need  for  Federal  Agencies  to  improve  the 
way  they  select  and  manage  information  technology  (IT)  resources  and  the  DoDAF  grew 
out  of  this  and  related  policies  that  identified  the  need  for  a  unified  architecture 
framework  to  be  applied  during  the  development  of  those  architecture  descriptions 
dictated  by  policy.50  An  architect  of  a  military  software-intensive  project  must  follow  the 
guidelines  as  dictated  by  the  framework. 

C.  RESEARCHING  ZF 

1.  Initial  Expectations 

In  1987,  John  Zachman,  author  of  the  Zachman  Framework  for  Enterprise 
Architecture,  wrote  “To  keep  the  business  from  disintegrating,  the  concept  of  information 
systems  architecture  is  becoming  less  of  an  option  and  more  of  a  necessity.”  From  that 
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assertion  over  15  years  ago,  the  Zachman  Framework  for  Enterprise  Architecture  has 
evolved  and  become  the  model  around  which  major  organizations  view  and  communicate 
their  enterprise  information  infrastructure.  After  studying  the  Zachman  framework,  the 
initial  expectations  of  the  user  is  to  be  able  to  apply  the  framework  simplistically,  in  a 
logical  manner,  and  comprehensively. 

The  Zachman  framework  is  simplistic  in  its  structure.  It  is  composed  of  six 
perspectives  which  are  represented  by  the  six  rows  of  the  framework:  from  the  top  down 
-  the  planner,  owner,  designer,  builder,  sub-contractor  and  the  functioning  enterprise; 
those  are  the  participants  involved  in  information  systems  planning,  development,  and 
usage.  The  framework  has  six  columns  which  are  its  aspects  and  they  answer  the  six 
interrogatives:  what,  how,  where,  who,  when  and  why.  At  the  intersection  of  the 
columns  and  rows  are  cells  which  are  a  unique  artifact  and  contains  a  unique  dimension 
that  cannot  be  found  in  another  cell.  The  framework  is  simplistic  in  this  manner. 

The  Zachman  framework  is  logical  in  that  an  architect  can  look  through  the  eyes 
of  each  perspective  and  examine  their  process  by  examining  each  individual  cell  in  their 
rows  and  those  cells  in  the  framework  can  be  presented  at  various  levels  of 
detail/granularity.  The  flow  of  details  and  information  follows  a  distinct  pattern  left  to 
right  on  the  rows  and  up  and  down  on  the  columns,  but  not  diagonally. 

The  Zachman  framework  is  comprehensive  in  that  it  encompasses  the  six 
interrogatives:  what,  how,  where,  who,  when  and  why.  Those  questions  are  assumed  to 
be  the  total  relevant  set  with  no  further  questions  that  can  be  asked.  Each  question  is 
unique  and  if  one  answers  all  six  questions  about  any  subject  or  object  -  that  represents 
completeness  and  total  comprehensiveness. 

2.  Initial  Pros 

The  proficiencies  of  the  Zachman  framework  are  too  numerous  and  making  a 
comprehensive  list  of  all  of  them  is  not  within  the  scope  of  this  document.  However, 
some  of  the  initial  pros  recognized  within  the  Zachman  framework  are  that  it  is 
organizational,  neutral,  is  a  networking  tool  and  is  an  excellent  methodology. 

The  Zachman  framework  is  organizational  in  that  it  has  dimension  necessity  and 
simplicity.  All  six  dimensions  are  needed  to  fully  represent  each  perspective  -  the 


31 


integration  of  all  cell  models  in  one  row  constitutes  a  complete  model  from  the 
perspective  of  that  row.  Each  column  has  a  simple,  basic  model  used  to  describe  a 
portion  of  the  enterprise  and  its  architecture.  These  models  are  not  independent:  rather 
they  are  interdependent  and  interact  continuously.  A  change  in  one  column  affects  one  or 
more  columns. 

The  Zachman  framework  is  neutral  in  that  it  can  be  applied  to  all  types  of 
projects.  Most  architecture  frameworks  are  project  specific;  they  are  useful  for  one  type 
of  activity.  However,  the  Zachman  framework  is  unique  in  that  it  answers  the  six 
interrogatives  for  any  project  and  it  encompasses  the  perspectives  that  are  used  in  all 
projects.  The  neutrality  of  the  Zachman  framework  makes  it  a  viable  instrument  for  use 
by  organizations  and  enterprises  of  all  types  and  sizes. 

The  Zachman  framework  is  a  networking  document  in  that  it  integrates  all  of  its 
cells  to  form  an  architecture  description.  The  cells  of  the  framework  are  the  result  of  the 
intersection  of  a  perspective  and  an  aspect;  they  form  a  unique  artifact  that  has  context 
and  dimension.  Each  cell  contains  graphic  and  textual  description  and  is  unique  in  that 
the  information  contained  within  its  boundaries  cannot  be  found  throughout  the 
framework.  It  is  the  final  integration  of  all  the  cells  that  form  the  enterprise. 

The  Zachman  framework  has  all  the  characteristics  of  an  excellent  methodology. 
It  address  the  full  life  cycle  of  an  enterprise,  integrates  a  set  of  processes,  provides 
executable  results,  communicates  well  to  all  audiences,  extends  ability  to  adjust  to 
specific  needs  and  has  been  applied  successfully. 

3.  Initial  Cons 

The  Zachman  framework,  like  all  other  products  used  for  enterprise  architecture, 
has  drawbacks,  hurdles,  shortcomings  and  disadvantages.  Most  of  those  consequences 
reside  within  the  document  itself.  Some  of  the  initial  cons  of  the  Zachman  framework  are 
that  it  is  primitive,  and  lacks  cognitive  and  business  direction. 

The  Zachman  framework  is  primitive  in  that  each  one  of  its  columns  answers  one 
of  the  six  interrogatives  of  the  English  language:  what,  how,  where,  who,  when  and  why. 
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While  this  is  a  comprehensive  approach  to  solving  the  design  problems  of  an  enterprise 
structure,  it  does  not  allow  for  decomposition  which  is  necessary  for  problem  solving  for 
the  complex  enterprise. 

The  Zachman  framework  lacks  cognitive  direction  in  that  it  does  not  give  concise 
direction  and  guidance  for  problem  solving.  It  is  not  a  document,  but  is  a  simple 
framework  and  as  a  result  it  does  not  provide  rules  and  regulations  for  its  usage.  The 
framework  is  generic  in  scope  and  is  not  tailored  to  a  specific  program  or  project.  It  does 
not  provide  technical  assistance  or  details  for  oversight  of  a  project. 

The  Zachman  framework  lacks  business  direction.  It  does  not  provide  details  for 
the  establishment  of  the  business  portion  of  an  enterprise  development.  In  the  words  of 
John  Zachman,  the  creator  of  the  Zachman  framework,  the  framework  is  not  designed  to 
sell  anything.  It  is  simply  a  classification  scheme  for  descriptive  representations  of 
complex  objects.  Business  rules,  guidance  and  direction  have  to  be  incorporated  by  the 
architect(s). 

D.  COMPARISON  OF  DODAF  TO  ZACHMAN  FRAMEWORK 

In  1987,  John  Zachman,  author  of  the  Zachman  Framework  for  Enterprise 
Architecture,  wrote  “To  keep  the  business  from  disintegrating,  the  concept  of  information 
systems  architecture  is  becoming  less  of  an  option  and  more  of  a  necessity.”  Zachman’ s 
concern  was  that  change  (especially  information  technology),  as  an  inevitable 
characteristic  of  human  endeavor,  was  not  being  recognized  and  addressed  by  the 
business  enterprise.  Drawing  upon  his  work  experience  in  information  systems, 
Zachman’ s  response  to  this  paradox  was  to  develop  and  introduce  the  Zachman 
Architecture  Framework  in  1987.  It  is  a  widely  used  approach  for  developing  and/or 
documenting  enterprise-wide  information  systems  architecture. 

“The  Defense  Science  Board  and  other  major  studies  have  concluded  that  one  of 
the  key  means  for  ensuring  interoperable  and  cost-effective  military  systems  is  to 
establish  comprehensive  architectural  guidance  for  all  of  DoD.”  [USD  (A&T),  ASD 
(C3I),  J6,  1997],  In  the  mid  1990’s  with  the  increasing  focus  on  joint  and  multinational 
operations,  DoD  realized  the  need  for  a  common  approach  for  describing  architectures. 
In  October  1995,  the  Deputy  Secretary  of  Defense  directed  that  a  DoD-wide  effort  be 
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undertaken  to  define  and  develop  better  means  and  processes  for  ensuring  that  Command, 
Control,  Communications,  Computers  and  Intelligence  capabilities  meet  the  needs  of  the 
warfighter.  The  C4ISR  Architecture  Framework,  Version  1.0,  dated  7  June  1996,  was 
developed.  The  utility  of  the  C4ISR  Architecture  Framework,  combined  with  both 
Federal  and  DoD  policy  encouraging  the  use  of  architectures,  led  DoD  to  evolve  the 
document  into  the  DoDAF  in  2003. 51 

The  Zachman  framework  is  a  way  of  thinking  about  an  enterprise  in  an  organized 
way  so  that  it  can  be  described  and  analyzed.  The  columns  represent  aspects  of  the 
enterprise  that  can  be  addressed,  and  the  rows  represent  various  viewpoints  from  which 
those  aspects  can  be  described.  At  the  intersection  of  a  column  and  row  is  a  cell  that 
represents  an  aspect  of  the  enterprise  modeled  from  a  particular  point  of  view.  The 
architect  selects  and  models  the  cells  that  are  appropriate  to  the  purpose  of  the  analysis.52 

Figure  6  is  illustrated  by  color  coding  and  shows  how  the  views  and  individual 
products  of  the  DoDAF  map  to  the  cells  of  the  Zachman  framework.  (The  figure  maps 
only  the  most  frequently-used  DoD  products,  not  all  of  them.) 

Blue  cells  indicate  that  DoDAF  contains  operational  view  products  that  map  to 
the  cells;  orange  cells  indicate  that  the  DoDAF  contains  system  products  that  map  to  the 
cells;  and  blue/orange  cells  indicate  that  the  DoDAF  contains  both  operational  and 
systems  products  that  map  to  the  cells.  The  ovals  have  been  overlaid  onto  the  color- 
coded  cells.  These  ovals  represent  individual  products  from  the  DoDAF  that  correspond 
to  the  Zachman  cell  or  cells  onto  which  the  oval  is  overlaid.  Operational  products  are 
represented  by  blue  ovals  and  systems  products  by  yellow  or  orange  ovals. 

In  some  instances  a  cell  is  blue  and  orange,  indicating  the  DoDAF  contains  both 
operational  and  systems  products  that  correspond  to  the  cell,  but  only  a  blue  oval  is 
shown  in  the  cell  because  not  all  DoDAF  products  are  represented.  The 
Function/Designer  cell  is  blue  and  orange  because  the  Operational  Activity  to  Systems 
Function  Matrix,  while  shown  in  the  DoDAF  as  a  system  view  product,  is  actually  a  pivot 
between  the  operational  and  systems  views. 
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Through  this  product-to-cell  mapping,  the  DoDAF  can  provide  templates  and 
guidelines  for  modeling  the  enterprise  features  that  correspond  to  the  Zachman  cells. 
Refer  to  Appendix  A  Table  1  to  map  DoDAF  product  names  to  the  framework  product 
and  general  description.53 
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Figure  6.  Mapping  of  selected  DoDAF  products  to  ZAF  cells 


E.  DEVELOPING  A  SURVEY 

1.  Deciding  Survey  Length 

This  thesis  will  analyze  and  compare  the  Department  of  Defense  Architecture 
Framework  and  Zachman  Architecture  Framework  for  use  as  the  USCG’s  WPC  System 
of  Systems  architecture.  At  the  beginning  of  the  project,  a  determination  was  made  to 
survey  a  pool  of  managers  and  directors  responsible  for  the  application  of  architecture 
frameworks  to  large,  complex  DoD  projects. 

A  short  survey  of  ten  questions  was  developed  because  many  of  the  managers  and 
directors  surveyed  have  many  constraints  placed  on  their  time. 
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2.  Establishing  Effective  Survey  Questions 

This  thesis  compares  two  architectures  for  use  as  the  USCG’s  WPC  System  of 
Systems  architecture.  To  avoid  random  data  collection,  the  survey  posed  to  the  managers 
and  directors  asked  basic  questions  concerning  their  use  of  Architecture  Frameworks. 
The  following  is  a  list  of  the  questions  used  in  the  survey: 

1.  Have  you  ever  participated  in  the  application  of  an  architecture 
framework?  (YES)  (NO) 

2.  Of  the  following  architecture  frameworks,  which  one(s)  have  you  used? 

Department  of  Defense  Architecture  Framework 
Zachman  Architecture  Framework 
Other  (please  specify) 

3.  Which  architecture  framework  would  you  recommend? 

Department  of  Defense  Architecture  Framework 
Zachman  Architecture  Framework 
Other  (please  specify) 

4.  Did  the  C4ISR  architecture  framework  used  on  your  project  - 

Add  value  to  the  project?  (YES)  (SOMETIMES)  (NO)  (NA) 

Create  unnecessary  work? 

Assist  in  the  architecture  development  of  the  project? 

Hinder  development  of  the  project? 

Increased  functionality  of  the  project? 

Have  clear  and  concise  documentation? 

5.  Did  the  Zachman  architecture  framework  used  on  your  project  - 

Add  value  to  the  project?  (YES)  (SOMETIMES)  (NO)  (NA) 

Create  unnecessary  work? 

Assist  in  the  architecture  development  of  the  project? 

Hinder  development  of  the  project? 

Increased  functionality  of  the  project? 

Have  clear  and  concise  documentation? 

6.  What  are  the  best  and  worst  functions  of  the  C4ISR  AF? 

7.  What  are  the  advantages  and  disadvantages  of  using  the  C4ISR  AF? 
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8.  What  are  the  best  and  worst  functions  of  the  Zachman  AF? 

9.  What  are  the  advantages  and  disadvantages  of  using  the  Zachman  AF? 

10.  In  your  opinion,  is  an  architecture  framework  needed  for  large  scale, 
complex  projects?  Explain. 

No  research  was  conducted  to  establish  questions  of  the  survey  or  the  length  of 
the  survey. 

F.  SUMMARY 

The  DoDAF  and  Zachman  frameworks  are  used  to  develop  enterprise  architecture 
descriptions.  The  DoDAF  is  primarily  used  by  DoD  contractors  and  Federal  Agencies  to 
provide  guidance  for  describing  architectures  for  both  warfighting  operations  and 
business  operations  and  processes.  Its  purpose  is  ensure  that  architecture  descriptions  can 
be  compared  and  related  across  organizational  boundaries,  including  Joint  and 
multinational  boundaries.54  The  Zachman  framework  is  a  widely  used  approach  for 
developing  and/or  documenting  enterprise-wide  information  systems  architecture.  Its 
purpose  is  to  provide  a  basic  structure  which  supports  the  organization,  access, 
integration,  interpretation,  development,  management,  and  changing  of  a  set  of 
architectural  representations  of  the  organizations  information  systems.55 

A  compilation  of  initial  expectations  met  by  the  DoDAF  include  an  ability  to 
apply  it  simplistically,  logically,  comprehensively  and  structurally.  Likewise,  the 
Zachman  framework  can  be  applied  simplistically,  logically  and  comprehensively. 

The  initial  proficiencies  of  the  DoDAF  are  that  is  highly  organized,  informational, 
and  is  a  great  networking  document.  Likewise,  the  Zachman  framework  is  highly 
organized,  a  neutral  document,  an  excellent  networking  tool  and  an  excellent 
methodology. 

The  initial  cons  of  the  DoDAF  are  that  it  is  cumbersome,  inelastic,  and 
unalterable,  while  the  Zachman  framework  is  primitive,  lacks  cognitive  and  business 
direction. 

Both  the  DoDAF  and  Zachman  frameworks  are  excellent  tools  used  to  provide 
structure  and  a  holistic  view  to  the  development  of  an  enterprise. 
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IV.  DATA  ANALYSIS 


A.  INTRODUCTION 

This  thesis  compares  two  architecture  frameworks  -  the  DoDAF  and  the  Zachman 
framework  for  use  in  developing  the  System  of  Systems  architecture  document  of  the 
USCG’s  WPC.  In  the  beginning  stages  of  this  project,  it  was  decided  to  poll  supervisors, 
managers,  and  directors  at  two  defense  contractors  (Northrop  Grumman  Ship  Systems 
and  Raytheon)  concerning  their  application  of  the  aforementioned  frameworks.  A  survey 
was  developed  and  sent  out  on  May  14,  2005  to  sixty-seven  supervisors,  managers  and 
directors  of  the  two  companies  mentioned,  polling  them  about  their  usage  of  the  DoDAF 
and  Zachman  framework.  There  were  eighteen  responses  to  the  survey,  which  is  a 
twenty-seven  percent  response  rate.  This  chapter  will  analyze  data  collected  from  the 
survey. 

B.  SURVEY  RESULTS 

1 .  Have  you  ever  participated  in  the  application  of  an  architecture  framework? 

•  Of  the  eighteen  responses,  seventeen  responded  yes  (94.4%)  and  one 
responded  no  (5.6%). 

2.  Of  the  following  frameworks  (DoDAF,  Zachman)  which  ones  have  you  used? 

•  Of  the  eighteen  responses,  thirteen  responded  DoDAF  (72.2%),  four 
responded  Zachman  (22.2%)  and  four  responded  ‘other’  (22.2%). 

3.  Which  architecture  framework  (DoDAF,  Zachman)  would  you  recommend? 

•  Of  the  thirteen  responses,  six  responded  DoDAF  (46.2%),  one  responded 
Zachman  (7.7%)  and  six  responded  ‘other’  (46.2%). 

4.  Did  the  DoDAF  (C4ISR)  architecture  framework  used  on  your  project  - 

•  Add  value  to  the  project? 

57%  yes,  36%  sometimes,  0%  no,  7%  not  applicable 

•  Create  unnecessary  work? 

0%  yes,  86%  sometimes,  7%  no,  7%  not  applicable 
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•  Assist  in  the  architecture  development  of  the  project? 

60%  yes,  33%  sometimes,  0%  no,  7%  not  applicable 

•  Hinder  development  of  the  project? 

7%  yes,  21%  sometimes,  64%  no,  7%  not  applicable 

•  Increased  functionality  of  the  project? 

23%  yes,  38%  sometimes,  31%  no,  8%  not  applicable 

•  Have  clear  and  concise  documentation? 

14%  yes,  71%  sometimes,  7%  no,  7%  not  applicable 

5.  Did  the  Zachman  architecture  framework  used  on  your  project  - 

•  Add  value  to  the  project? 

8%  yes,  8%  sometimes,  0%  no,  85%  not  applicable 

•  Create  unnecessary  work? 

0%  yes,  15%  sometimes,  0%  no,  85%  not  applicable 

•  Assist  in  the  architecture  development  of  the  project? 

15%  yes,  0%  sometimes,  0%  no,  85%  not  applicable 

•  Hinder  development  of  the  project? 

0%  yes,  15%  sometimes,  0%  no,  85%  not  applicable 

•  Increased  functionality  of  the  project? 

8%  yes,  8%  sometimes,  0%  no,  85%  not  applicable 

•  Have  clear  and  concise  documentation? 

0%  yes,  15%  sometimes,  0%  no,  85%  not  applicable 

6.  What  are  the  best  and  worst  functions  of  the  DoDAF? 

•  Of  eighteen  responders,  five  answered  this  question  as  follows: 

a.  Sometimes  can  be  more  of  a  hindrance  then  helpful 

b.  Best  -  relational  data  repository  pictorial  representation  of  the  data; 
Worst  -  inconsistency  of  interpretation  by  some  users. 

c.  What  is  a  ‘function’  of  a  framework? 
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d.  Best  -  defines  some  standard  products  and  relationships  between  them; 
Worst  -  doesn’t  define  a  process,  doesn’t  help  with  some  architectural 
perspectives,  and  totally  misses  the  boat  on  hierarchical  architectural 
relationships. 

e.  Don’t  understand  the  question. 

7.  What  are  the  advantages  and  disadvantages  of  using  the  DoDAF? 

•  Of  eighteen  responders,  seven  responded  to  this  question. 

a.  Adv  -  organize  thoughts;  Dis  -  Sometimes  can  be  more  of  a  hindrance 
then  helpful. 

b.  The  documentation  is  very  loose  and  easily  interpreted  in  many 
different  ways.  This  can  make  it  difficult  during  the  creation  of  certain 
products  when  people  on  the  same  project  have  different  ideas  as  to  what 
the  product  ‘should  be’.  Also,  special  attention  needs  to  be  paid  to  the 
entire  framework  and  how  the  whole  product  set  is  to  work  together.  This 
can  help  alleviate  issues  with  different  interpretations  of  the 
documentation  and  limit  issues  later. 

c.  Zealousness  of  management  to  ensure  that  every  work  product  include 
every  CAF/DoDAF  artifact  results  in  numerous  poor  quality  artifacts  that 
don’t  tell  you  anything.  For  example,  including  SV  artifacts  in  a 
preliminary  requirements  project.  There  isn’t  much  understanding  in  our 
industry  about  what  an  artifact  should  show  and  when  to  use  it.  Our 
company  should  invent  in  very  detailed  training  for  system  engineers. 

d.  Advantage:  pictorial  representation  of  the  data  organized  relational  data 
repository;  disadvantage:  when  the  architecture  teams  try  to  duplicate 
work  that  is  being  done  by  another  group;  thus  causing  double  work  and 
sometimes  lack  of  consistency  tool  use  by  all  of  the  team  would  increase 
the  understanding  and  consistency  of  product. 
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e.  Advantage:  commonality  across  most  DoD  programs;  Disadvantage: 
too  few  views;  many  significant  concepts  have  no  natural  home  (e.g., 
information  assurance  (security)  architecture). 

f.  People  understand  what  an  OV-x  or  SV-y  view  is  supposed  to  represent. 

g.  The  advantages  are  that  it  provides  documentation  of  existing  C4ISR 
system  architectures  and  instills  some  discipline  into  the  architecting 
process.  The  disadvantage  is  that  it  does  not  provide  a  concise  over¬ 
arching  view  of  the  entire  architecture.  One  has  to  page  through  the 
various  views  and  try  to  remember  them  all  in  order  to  obtain  a  coherent 
picture. 

8.  What  are  the  best  and  worst  functions  of  the  Zachman  Architecture 
Framework? 

•  Of  the  eighteen  responders,  six  answered  this  question  as  follows: 

a.  NA 

b. NA 

c.  not  applicable 

d.  NA 

e.  Best  -  it’s  a  great  thinking  tool.  Worst  -  probably  not  a  great  way  to 
describe  architecture. 

f.  Haven’t  used  it. 

9.  What  are  the  advantages  and  disadvantages  of  using  the  Zachman  Architecture 
Framework? 

•  Of  the  eighteen  responders,  six  answered  this  question. 

a.  NA 

b. NA 

c.  not  applicable 
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d.  NA 


e.  It’s  a  great  tool  for  thinking  about  an  architecture,  and  structuring 
analysis. 

f.  Haven’t  used  it. 

10.  In  your  opinion,  is  an  architecture  framework  needed  for  large  scale,  complex 
projects?  Explain. 

•  Of  the  eighteen  responders,  nine  answered  this  question  as  follows: 

a.  Yes.  As  indicated  in  the  question,  the  complexity  of  such  projects  must 
have  architecture  framework  to  succeed. 

b.  It  is  helpful  to  use  a  framework  to  capture  the  whole  project.  Using  a 
well-known  framework  makes  it  easy  to  understand  for  those  outside  of 
the  project.  It  also  helps  to  ensure  that  everything  is  being  covered. 

c.  Yes,  if  implemented  consistently  and  with  sufficient 
documentation/instruction  to  team  members  an  architecture  framework 
greatly  decreases  the  learning  curve  to  understand  the  system  and 
improves  understanding  of  the  architecture  details. 

d.  Yes,  the  customer  understands  the  data.  The  team  understands  the  data 
from  a  team  perspective. 

e.  No.  It  is  more  important  to  have  an  architecture  process  than  a  product 
framework.  The  process  should  describe  the  products.  The  framework  is 
useful  (but  not  sufficient)  for  the  development  of  the  process. 

f.  Yes,  but  it  must  be  tightly  coupled  with  the  requirements  tool(s) 
[DOORS]  as  well  as  within  itself. 

g.  I  think  it’s  far  more  important  that  the  architects  understand  frameworks 
that  exist  and  use  the  products,  views,  processes,  etc.  that  help  with  the 
particular  project. 

h.  Yes 
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i.  Yes,  a  framework  is  needed.  If  no  framework  is  used  there  is  no 
assurance  that  an  architecture  is  correct.  Also,  since  most  systems  need  to 
be  interoperable,  architectures  must  be  explained  in  some  standard 
notation  so  that  interoperability  can  be  readily  assessed. 


C.  SUMMARY 

As  a  part  of  this  thesis  process,  a  survey  was  developed  to  assess  how  many 
technical  directors,  managers  and  supervisors  have  used  the  DoDAF  or  Zachman 
frameworks.  The  survey  also  assessed  the  advantages,  disadvantages  and  the  need  for  an 
architecture  framework  in  developing  large-scale,  complex,  software-intensive 
enterprises.  The  purpose  of  a  survey  is  to  collect  information  for  use  in  improving 
products  or  processes.  Once  information  is  collected  it  must  be  assessed  so  its  results  can 
be  put  to  effective  use.  Of  the  sixty-seven  architects,  directors,  managers  and  supervisors 
the  survey  was  sent  to,  eighteen  responded  and  their  comments  are  recorded  in  section  B. 
This  summary  will  catalog  and  assess  the  responses  and  comments  of  the  survey. 

The  survey  had  a  variety  of  questions  and  they  are  cataloged  as  directive, 
informational,  and  functional.  Questions  1-3  asked  the  survey  takers  for  their  direction. 
Questions  4  and  5  supplied  information  for  the  survey  takers  so  they  could  provide  an 
assessment  of  the  functional  aspects  of  the  framework  that  they  had  experience  with. 
Questions  6-10  queried  the  survey  takers  for  working  knowledge  and  information 
pertaining  to  their  experience  in  the  application  of  an  architecture  framework. 

This  is  a  summary  of  the  assessment  of  the  information  provided  by  the 
responders  to  this  survey.  The  majority  (94.4%)  of  responders  had  used  an  architecture 
framework  during  their  career  and  most  (72.2%)  had  used  the  DoDAF,  while  only 
twenty-two  percent  had  used  the  Zachman  framework.  Forty-six  percent  of  the 
responders  would  recommend  the  usage  of  the  DoDAF,  while  seven  percent  would 
recommend  the  usage  of  Zachman  framework.  As  indicated  by  the  results,  the  majority 
of  DoDAF  users  indicated  that  value  was  added  to  their  work,  sometimes  unnecessary 
work  was  created  by  the  use  of  the  framework,  the  architecture  development  of  the 
project  was  aided,  did  not  hinder  project  development,  increased  functionality  of  their 
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project,  and  the  framework  had  clear  and  concise  documentation.  As  indicated  by  the 
results,  the  majority  of  Zachman  framework  users  indicated  that  value  was  added  to  their 
work,  the  use  of  the  framework  sometimes  added  unnecessary  work,  the  architecture 
development  of  the  project  was  aided,  sometimes  project  development  was  hindered,  the 
functionality  of  their  project  increased  and  the  framework  had  clear  and  concise 
documentation. 

Based  on  the  comments  received,  some  advantages  of  using  the  DoDAF:  a  way 
of  organizing  thoughts,  good  as  a  pictorial  representation  of  data  repository,  a  way  of 
establishing  commonality,  and  a  way  of  instilling  discipline  in  the  architecture  process. 
Some  disadvantages  to  using  the  DoDAF:  can  cause  double  work,  views  can  be 
interpreted  many  ways,  does  not  provide  over-arching  or  holistic  view  of  project,  and  has 
too  few  views. 

Based  on  the  comments  received,  the  advantages  of  using  the  Zachman 
framework  are  that  it  is  a  great  tool  for  thinking  about  a  process  and  structuring  analysis. 
A  disadvantage  to  using  the  Zachman  framework  is  that  it  is  not  a  great  way  to  describe 
an  architecture. 

The  last  question  of  the  survey  asked  if  the  use  of  an  architecture  framework  is 
necessary  for  large  scale,  complex  projects.  The  overwhelming  response  was  that  an 
architecture  is  needed  to  structure  the  processes  of  developing  an  interoperable,  network 
of  systems.  The  results  of  this  survey  indicated  that  in  DoD  acquisition  projects  at 
Northrop  Grumman  Ship  Systems  and  Raytheon,  the  DoDAF  is  the  framework  of  choice. 


45 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


46 


V.  IMPLEMENTATION  OF  ARCHITECTURE  FRAMEWORK 


A.  INTRODUCTION 

“When  Deepwater  is  complete,”  said  Coast  Guard  Commandant  ADM  Thomas  H. 
Collins,  “our  cutters  and  aircraft  will  no  longer  operate  as  independent  platforms  with 
only  limited  awareness  of  what  surrounds  them  in  the  maritime  domain.  Instead,  they 
will  have  the  benefit  of  receiving  information  from  a  wide  array  of  mission-capable 
platforms  and  sensors  -  enabling  them  to  share  a  common  operating  picture  as  a  part  of  a 
network-centric  force  operating  in  tandem  with  other  cutters,  boats,  and  both  manned 
aircraft  and  unmanned  aerial  vehicles.”56 

The  Deepwater  system  of  systems  is  a  collection  of  different  elements  that 
together  produce  results  not  obtainable  by  the  individual  elements  alone.  These  include 
platform  systems  (aircraft,  cutters  and  patrol  boats),  sub-systems  (radars,  radios,  satellite 
communications,  etc.)  as  well  as  individual  components  and  assets  (people,  hardware, 
software,  shore  facilities). 

All  elements  combine  to  generate  capabilities  needed  to  produce  system-wide 
results.  The  value  added  by  the  system  as  a  whole,  beyond  that  contributed 
independently  by  its  individual  elements,  is  created  by  the  integration  among  the 
elements  (i.e.,  how  they  are  interconnected  and  combined  in  order  to  work  together). 

The  elements  are  being  designed  to  ensure  the  Coast  Guard  will  possess  and 
maintain  seamless  interoperability  with  the  forces  and  agencies  of  the  Department  of 
Homeland  Security,  the  Department  of  Defense  (DoD),  and  other  federal  and  regional 
agencies  -  a  true  force  multiplier  in  the  fullest  sense.57 

Extensive  studies  of  the  all  Coast  Guard  mission  areas  takes  into  account  detailed 
operational  modeling  of  platforms  and  systems,  optimized  force  mixes  of  varying  size, 
asset  application  using  various  concepts  of  operation  and  timed  incremental 
implementations  across  the  life  of  the  program. 

Since  the  terrorist  attacks  inside  the  United  States  on  September  11,  2001,  the 

Coast  Guard’s  mission  demands,  threats  and  operational  priorities  have  changed 

considerably  -  including  a  40  percent  increase  in  resource  usage  and  an  exponential 
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expansion  of  homeland  security  requirements.  Because  of  the  need  to  remain  flexible 
and  responsive,  the  Deepwater  program  needs  to  be  built  upon  a  spiral  development  in 
order  to  respond  to  evolving  technology  or  changes  in  mission  requirements. 


Figure  7.  Spiral  Development 


The  spiral  development  as  outlined  in  Figure  7  and  proposed  by  Barry  Boehm  in 
mid- 1980  is  used  extensively  for  software  intensive  programs,  but  the  principles  can  be 
used  for  enterprises  of  all  types.  The  IJSCG  Deepwater  program  is  slated  to  mature  in 
2022  and  it  will  have  to  accommodate  many  upgrades  in  capabilities  until  its  completion. 
Spiral  development  establishes  requirements  in  an  iterative  process,  by  partitioning 
capabilities  that  can  be  defined,  developed,  refined,  and  matured  without  causing  rippling 
dependencies  among  other  capabilities.  The  spiral  process  encourages  in-stream 
improvement  and  refinement  that  allows  system  developers  to  upgrade  capabilities 
incrementally  until  the  system  fully  meets  customer  expectations.  Each  spiral  can 
accommodate  successive  iterations  of  requirements  development  and  solutions  testing, 
starting  from  broad  aspects  and  progressing  (i.e.  spiraling)  toward  more  specific 
aspects.58 
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The  USCG  Deepwater  program  will  need  constant  reevaluation  so  that  changing 
needs,  missions  and  new  technology  can  be  incorporated  into  the  system  of  systems  over 
the  life  of  the  program.  The  WPC,  as  an  asset  of  the  Deepwater  program,  will 
incorporate  spiral  development  that  will  enable  it  to  be  interoperable  and  interconnected 
successfully  in  the  network-centric  maritime  domain  in  which  it  will  operate. 

B.  RECOMMENDED  ARCHITECTURE  FRAMEWORK 

The  USCG  is  the  world’s  tenth  largest  navy  and  as  a  small  navy  it  must  take  its 
place  in  the  world  of  network-centric  warfare.  The  Coast  Guard  is  part  of  the  new 
Department  of  Homeland  Security;  however  during  periods  of  conflict,  such  as  the  Gulf 
War  and  prior  to  that,  World  War  I  and  II,  the  service  is  assigned  to  the  Department  of 
Defense. 

In  an  effort  to  present  the  two  services  as  a  holistic  force,  Coast  Guard 
Commandant  Adm.  Thomas  H.  Collins  and  Chief  of  Naval  Operations  Adm.  Vern  Clark 
signed  a  National  Fleet  Policy  that  stipulates  the  sea  services  will  maximize  the 
effectiveness  of  Coast  Guard  and  Navy  forces  across  their  maritime  and  naval  missions. 

In  effect,  the  WPC’s  mission  includes  the  ability  to  be  fully  interoperable  and 
interconnected  in  the  network-centric  maritime  domain.  This  will  enable  the  WPC  to 
receive  classified  and  unclassified  data  previously  unavailable,  be  aware  of  its  maritime 
surroundings  and  to  conduct  missions  in  synchronization  with  Coast  Guard  and  Naval 
operations. 

The  Coast  Guard  and  United  States  Navy  are  going  to  synchronize  their  activities 
and  conduct  missions  in  parallel.  The  scope  of  the  WPC  requires  spiral  development 
which  requires  a  framework  that  has  inherent  ways  to  effect  interoperability  within  the 
DoD  net-centric  realm,  manage  risk,  and  provide  a  means  of  cascading  development.  The 
DoDAF  provides  a  firm  architectural  underpinning  for  all  elements  of  the  WPC  to  be 
interoperable  and  is  recommended  to  be  used  as  the  architecture  framework  for  the 
system  of  systems  architecture  document  for  the  WPC. 

The  United  States  Navy  uses  the  DoDAF  to  build  its  programs;  this  effort  is 
intended  to  present  a  common  language,  foster  improved  integration  of  requirements  and 
acquisition  processes,  support  interoperability  and  affordability.  The  Coast  Guard  will 
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conduct  their  missions  separate  from  the  Navy  but  with  the  ability  to  be  interconnected  to 
the  Navy  and  its  missions;  therefore  the  DoDAF  allows  the  USCG  to  develop  their 
programs  and  platforms  with  the  same  integrated  architectures  as  the  Navy. 

The  DoDAF  allows  for  spiral  development  by  the  providing  products  that  can  be 
repeatedly  iterated  through  a  set  of  elemental  development  processes;  those  products  are 
based  on  its  three  views:  OV,  SV  and  the  TV.  The  DoDAF  can  be  used  to  promote 
interoperability  and  efficiency  through  the  use  of  its  framework  products,  which  have  the 
capabilities  of  description  -  graphical  and  textually. 

C.  FLAWS  OF  ARCHITECTURE  FRAMEWORK 

The  DoDAF  is  used  by  the  military  to  develop  software-intensive  programs  to  be 
installed  on  their  platforms.  This  framework  allows  the  services  to  produce  integrated 
architectures  which  provide  a  logical,  structured  approach  for  defining  how  forces 
operate,  the  associated  information  flow,  the  relation  between  that  information  flow  and 
system  capabilities,  and  the  relation  between  system  capabilities  and  technical 
standards.59  The  services  are  able  to  conduct  network-centric  warfare  in  Battle  Theater 
by  using  the  architecture  description  developed  as  a  result  of  the  use  of  the  DoDAF. 

All  major  documents  for  use  in  the  development  of  enterprise  architectures  have 
flaws  and  two  major  flaws  of  the  DoDAF  are  its  cumbersomeness  and  lack  of  business 
direction. 

The  DoDAF  consist  of  three  major  documents  which  contribute  to  its 
unwieldiness.  To  understand  how  to  apply  DoDAF,  one  needs  to  read  pertinent  sections 
of  two  of  the  volumes.  In  volume  I,  it  is  essential  that  sections  3  (Architecture  Uses),  4 
(Techniques  for  Using  Architecture  Information)  and  5  (Architecture  Guidelines, 
Description  Process,  and  Integration)  be  read  and  understood.  The  entire  contents  of 
volume  II  should  be  read  to  understand  which  of  the  26  views  needs  to  be  applied  to 
one’s  enterprise  development.  At  a  minimum,  both  AVs,  the  first  three  of  the  OVs,  the 
first  six  of  the  SVs  and  both  of  the  TVs  need  to  be  applied  to  a  DoD  project  using  the 
DoDAF  (see  Appendix  A  for  product  listings).  Provided  that  one  is  the  lead  architect  of 
a  project,  he/she  needs  to  understand  most,  if  not  all,  of  the  26  views  that  can  be  applied 
to  an  architecture  description. 
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The  DoDAF  provides  for  technical  guidance  within  all  of  its  framework  products. 
The  AV  products  capture  overarching  aspects  of  architecture  that  relates  to  all  three  of 
the  views  and  provides  pertinent  information  to  the  entire  architecture.  The  OV  describes 
the  task  and  activities,  operational  elements,  and  information  exchanges  to  accomplish 
DoD  missions.  The  SV  describes  a  set  of  graphical  and  textual  products  that  describes 
systems  and  interconnections  providing  for,  or  supporting,  DoD  functions.  The  TV 
encompasses  the  minimal  set  of  rules  governing  the  arrangement,  interaction,  and 
interdependence  of  system  parts  or  elements. 

Within  volume  I  on  page  1-2,  section  1.3.2,  the  following  statement  is  made 
relating  to  the  SV:  The  SV  describes  a  set  of  graphical  and  textual  products  that 
describes  systems  and  interconnections  providing  for,  or  supporting,  DoD  functions. 
DoD  functions  include  both  warfighting  and  business  functions.  After  researching  the 
SV  products,  it  was  found  that  none  of  them  addressed  business  functions.  The  DoDAF 
does  not  illustrate  sound  business  reasons  for  the  selection  of  one  approach  or  technology 
over  another. 

D.  RECOMMENDED  MODIFICATIONS  TO  FRAMEWORK 

Based  on  research  and  survey  conducted,  this  thesis  recommends  that  the  DoDAF 
be  selected  to  develop  the  system  of  system  architecture  document  for  the  USCG’s  WPC. 
After  studying  the  DoDAF  two  flaws  were  recognized:  1)  The  DoDAF  is  too 
cumbersome  and  2)  it  does  not  illustrate  sound  business  reasons  for  the  selection  of  one 
approach  or  technology  over  another.  This  section  will  recommend  modifications  to  the 
DoDAF  for  the  aforementioned  flaws. 

The  DoDAF  is  too  cumbersome  and  to  alleviate  that,  some  of  the  OV  and  SV 
products  can  be  combined.  The  OV-5,  OV-6b  and  OV-6c  which  describes  operational 
activities,  the  OV-2  and  OV-3  which  describes  information  exchange  can  be  combined 
and  simplified.  The  SV-1  and  SV-2  which  identifies  nodes  and  their  relationships,  the 
SV-4,  SV-5,  SV-6,  SV-lOa,  SV-1  Ob  and  SV-lOc  which  details  functions,  maps  functions 
and  provides  details  of  system  data  elements,  can  be  combined  and  simplified.  One 
answer  to  the  survey  complained  that  “One  has  to  page  through  the  various  views  and  try 
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to  remember  them  all  in  order  to  obtain  a  coherent  picture.”  This  action  of  combining 
and  simplifying  the  framework  would  help  to  create  an  over-arching  view  of  the  entire 
architecture  description. 

To  enhance  the  DoDAF  efforts  to  provide  concise  business  direction,  this  thesis 
recommends  adding  a  Motivational  View  (MV)  as  developed  by  D.  B.  Robi.60  The  MV 
would  include  the  necessary  business,  financial,  and  investment  models  required  to 
evaluate  and  prioritize  the  transition  alternatives  and  modernization  plans,  thus  providing 
a  solid  business  foundation  and  rationale  of  why  changes  need  to  be  made.  The  work 
products  are  as  follows: 


MV-1:  Business  Case 
MV-2:  Investment  Decision  Model 
MV-3:  Risk  Analysis  Model 
MV-4:  Best- Value  Low-Risk  Model 
MV-5:  Balanced  Scorecard  Model 


The  business  case  addresses  the  rationale  for  investing  the  time  and  resources  into 
making  the  necessary  changes  to  transform  the  current  as-is  to  the  targeted  to  be 
enterprise  architecture. 

The  investment  decision  model  (Figure  7)  provides  a  mechanism  to  perform  an 
analysis  of  cost  versus  benefit  to  drive  the  decision-making  process. 


Figure  8.  MV-2: 
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The  risk  analysis  model  (Figure  8)  provides  a  vehicle  to  identify  and  analyze  risk, 
which  is  the  probability  of  occurrence  and  impact  on  occurrence. 
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Figure  9.  MV-3  Risk  Analysis  Model 

The  best-value  low-risk  model  provides  the  next  step  in  selecting  the  best 
alternatives  by  taking  a  second  look  at  the  investment  decision  model  and  comparing  the 
best-value  candidates  on  the  basis  of  risk  (Figure  9). 


Figure  10.  MV-4  Best-value  Low-risk  Model 

The  balanced  scorecard  model  is  used  to  provide  a  common  standard  model  to 
manage  the  business  and  enterprise  architecture,  as  shown  in  Figure  11. 
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Figure  11.  MV-5:  Balanced  Scorecard  Model 


The  DoDAF  views  do  not  capture  the  business  prospective  needed  to  develop  a 
sound,  transitional  plan  from  as-is  to  to-be  as  required  in  today’s  architectural  projects. 
However,  the  Motivational  Views  described  seek  to  capture  the  missing  business 
perspective,  compliment  the  existing  DoDAF  views,  and  provide  a  complete  holistic 
view  of  enterprise  architecture.61 
E.  SUMMARY 

There  are  many  documents,  methodologies  and  frameworks  that  can  be  used  to 
develop  enterprise  architecture  descriptions  and  they  all  have  inherited  flaws  within  the 
document  themselves.  This  thesis  has  identified  two  flaws  within  the  DoDAF:  1)  It  is 
too  cumbersome  and  2)  It  lacks  business  direction.  These  flaws  are  not  all- 
encompassing,  but  are  pointed  out  to  show  the  inefficiencies  that  are  brought  on  by 
providing  too  much  information  in  one  area  of  the  framework  and  not  enough 
information  in  other  aspects  of  the  framework. 

This  thesis  proposes  modifications  to  the  DoDAF  that  may  prove  to  be  helpful  in 

alleviating  the  cumbersomeness  of  the  document  and  provide  business  direction.  One 

area  of  concern  is  the  proliferation  of  framework  products.  There  are  3  views:  the  OV, 

SV  and  TV  and  combined  with  the  AV,  the  views  have  26  framework  products  between 

them.  It  is  proposed  to  combine  some  of  the  views  that  have  similar  characteristic  such 
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as  the  OV-5,  0V-6b  and  0V-6c  which  describe  operational  activities.  These 
modifications  will  streamline  the  process  of  selecting  the  correct  framework  product  to 
suit  the  enterprise  project.  To  provide  business  direction,  this  thesis  proposes  that  a 
Motivational  View  be  added  to  the  framework.  This  view  would  consist  of  5  products: 
1)  The  business  case,  2)  investment  decision  model,  3)  risk  analysis  model,  4)  best- value 
low-risk  model  and  5)  balanced  scorecard  model.  These  modifications  will  illustrate 
sound  business  reasons  for  selecting  one  technology  or  approach  over  another. 

These  modifications  would  be  helpful  to  the  lead  architect  of  an  enterprise 
project,  by  streamlining  processes  and  providing  business  direction  and  giving  him/her  a 
holistic  view  of  the  enterprise  project. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  United  States  Coast  Guard  has  been  defending  the  United  States  coastline, 
rescuing  people  from  dangerous  situations,  and  protecting  the  citizens  of  the  U.S.  for  over 
two  and  a  half  centuries.  Its  mission’s  objectives  are  as  stated: 

Maritime  Security  Missions 

Drug  Interdiction 

EEZ  &  Living  Marine  Resource  Law/Treaty  Enforcement 
Maritime  Safety  Missions 
Search  and  Rescue 
Marine  Safety 
Recreational  Boating  Safety 
International  Ice  Patrol 
Protection  of  Natural  Resources  Mission 
Marine  Environmental  Protection 
Domestic  Fisheries  Enforcement 
Protected  Living  Marine  Resource  Law  Enforcement 
Maritime  Mobility  Missions 
Aids  to  Navigation 
Icebreaking  Services 
Bridge  Administration 
Waterway  s/V essel  Traffic  Management 
National  Defense  Missions 

General  Defense  Operations 


57 


Maritime  Interception  Operations 
Military  Environmental  Response  Operations 
Port  Operations,  Security,  and  Defense 
Peacetime  Military  Engagement 
Coastal  Sea  Control  Operations 
Polar  Icebreaking 

The  Coast  Guard  has  been  stretched  to  capacity  to  fulfill  its  missions  and  the 
tragic  events  of  September  11,  2001  compounded  the  strain  on  the  Coast  Guard’s  aging 
resources  by  adding  additional  responsibilities  to  the  agency.  It  is  estimated  that  the 
Coast  Guard’s  duties  increased  by  40%  in  matters  related  to  national  security  after 
9/11/2001. 

In  the  mid  1990s  a  commission  was  formed  to  study  how  to  remedy  the  gaps  in 
asset  acquisition.  Formerly,  the  Coast  Guard  replaced  ships  and  aircraft  on  a  one-to-one 
basis  as  needed.  This  approach  wasted  time,  money  and  resources  and  did  not  give  the 
Coast  Guard  a  secure  asset  foundation.  The  commission  recommended  that  the 
Integrated  Deepwater  System  (IDS)  be  formed  to  upgrade  existing  platforms  to  integrate 
with  naval  forces  and  to  acquire  new  platforms  that  would  perform  its  duties  within  a 
maritime  domain.  The  development  of  the  new  platforms  would  cover  maintenance 
planning,  manpower,  supply  support,  technical  manuals,  training  tools,  and  computer 
support. 

The  IDS  proposed  that  three  classes  of  cutters  be  acquired:  1)  The  WMSL,  2)  the 
WMSM  and  3)  the  WPC.  The  large  cutters  would  have  soft-kill  capabilities  and  be  able 
to  deploy  for  extended  periods  while  the  smaller  cutter  (WPC)  would  be  used  for  drug 
interdiction  and  law-enforcement  duties.  Based  on  mission  need,  it  was  thought  that  the 
system  of  system  architecture  document  could  be  developed  using  another  architecture 
framework  besides  the  DoDAF  that  was  used  to  develop  the  system  of  systems 
architecture  document  for  the  larger  cutters. 

This  thesis  compares  the  Zachman  architecture  framework  and  DoDAF  for  use  as 

the  system  of  systems  architecture  framework  for  the  WPC.  During  the  comparison  of 
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the  two  architecture  framework,  it  was  recognized  that  the  Zachman  architecture 
framework  is  an  excellent  methodology,  excellent  thinking  tool,  and  simplistic  to  use. 
However,  some  of  the  drawbacks  to  using  the  Zachman  are  that  it  does  not  provide 
business  direction,  does  not  provide  cognitive  direction  and  is  primitive.  Likewise  the 
DoDAF  is  comprehensive,  highly  organized  and  a  great  networking  document.  However, 
some  drawbacks  to  using  DoDAF  are  that  it  is  too  cumbersome,  inelastic,  and 
unalterable. 

A  survey  was  sent  to  sixty-seven  technical  directors,  managers,  supervisors  and 
architects  of  Northrop  Grumman  Ship  Systems  and  Raytheon  Corporation.  Eighteen 
individuals  responded  and  their  overwhelming  choice  of  architecture  framework  for  use 
is  the  DoDAF.  And  most  of  them  agreed  that  an  architecture  framework  must  be  used  for 
the  development  of  large-scale  complex  enterprises. 

Based  on  the  need  for  the  Coast  Guard  to  integrate  and  be  fully  interconnected 
with  the  United  States  Navy’s  C4ISR  systems,  to  follow  a  step-by-step  organizational 
process,  and  be  comprehensive  in  scope,  this  thesis  recommends  that  the  DoDAF  be 
chosen  as  the  architecture  framework  for  the  WPC’s  system  of  systems  architecture 
document. 

B.  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

This  thesis  did  not  consider  the  avenue  of  using  multiple  frameworks  to  develop 
the  WPC’s  system  of  systems  architecture  document.  One  could  conceivably  use  one 
framework  to  develop  lower  level  sub-systems  and  use  another  framework  to  develop  the 
overall  enterprise.  This  methodology  should  be  researched  for  use  on  other  large-scale 
complex  DoD  projects. 

Another  avenue  not  taken  by  this  thesis  is  the  use  of  the  DoD  Enterprise  Architecture  2 
Business  Reference  Model  in  conjunction  with  the  DoDAF  for  use  as  a  business/technical 
framework.  Further  research  should  be  conducted  to  analyze  if  the  two  frameworks  can 
be  used  together  to  capture  the  business  activities  of  enterprise  development. 
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APPENDIX 


Table  1.  Architectural  Products  [C41SRAF  97] 

Table  1:  Architectural  Products  [C4ISRAF  97] 


Applicable 

View 

Framework 

Product 

Framework  Product 

N  aine 

General  Description 

All  Views 

AY-1 

Overview  and 

Summary  Information 

Scope,  purpose,  intended  users,  environment 
depicted,  analytical  findings 

AY-2 

Integr  ated  Dictionary 

Data  repository  with  definitions  of  all  terms 
used  in  all  products 

OV-1 

High-Level 

Operational  Concept 
Graphic 

High-level  graphicahtextual  description  of 
operational  concept 

OY-2 

Operational  Node 
Connectivity 

Description 

Op er national  nodes,  operational  activities 
performed  at  each  node,  connectivity  and 
information  exchange  needlines  between  nodes 

OV-S 

Operational 

Information  Exchange 
Matrix 

Information  exchanged  between  nodes  and  the 
relevant  attributes  of  that  exchange 

OY-4 

Organizational 
Relationships  Chart 

Organizational,  role,  or  other  relationships 
among  organizations 

Op  eiation  a  l 

OX-5 

Operational  Activity 
Model 

Operational  activities  and  relationships  among 
activities,  inputs,  and  outputs.  Overlays  can 
show  cost,  performing  nodes,  or  other 
pertinent  information. 

GV-6a 

Operational  Rules 

Model 

One  of  the  three  products  used  to  describe  the 
operational  activity  sequence  and  timing; 
identifies  business  rules  that  constrain 
operation 

OV-6b 

Operational  State 
Transition  Description 

One  of  three  products  used  to  describe  the 
operational  activity  sequence  and  timing; 
identifies  business  process  responses  to  events 

OV-Gc 

Operational  Event- 
Trace  Description 

One  of  three  products  used  to  describe  the 
operational  activity  sequence  and  timing; 
traces  actions  in  a  scenario  or  sequence  of 
events  and  specifies  the  timing  of  events 

OV-7 

Logical  Data  Model 

Documentation  of  the  data  requirements  and 
structural  business  process  rules  of  the  OV. 
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Table  1 :  Architectural  Products  [C4ISRAF  97]  (continued) 


Applicable 

View 

Framework 

Product 

Framework  Product 
Name 

General  Description 

SV-1 

Systems  Interface 
Description 

Identification  of  systems  and  system  components 
and  their  interconnections,  within  and  between 
nodes 

SY-2 

Systems 

Communications 

Description 

Physical  nodes  and  their  related  communications 
laydowns 

SV-3 

S  y  s  t  e  ms-Sy stems 

Matrix 

Relationships  among  systems  in  a  given 
architecture;  can  be  designed  to  show  relationships 
of  interest  (e.g.,  system-type  interfaces,  planned  vs. 
existing  interfaces). 

SV-4 

Systems 

Functionality 

Description 

Functions  performed  by  systems  and  the 
information  flow  among  system  functions 

SV-5 

Operational 

Activity  to  Systems 
Function 

Fraceability  Matrix 

Mapping  of  systems  back  to  operational  capabilities 
or  of  system  functions  back  to  operational  activities 

SV-6 

Systems  Data 
Exchange  Matrix 

Provides  details  of  systems  data  being  exchanged 
betw  een  systems 

Systems 

SV-7 

Systems 

Performance 
Parameters  Matrix 

Performance  characteristics  of  each  system’s 
hardware  and  software  elements,  for  the 
appropriate  time  frame 

sv-s 

Systems  Evolution 
Description 

Planned  incremental  steps  toward  migrating  a  suite 
of  systems  to  a  more  efficient  suite,  or  toward 
e vo King  a  current  system  to  a  futur  e 
implementation 

SV-9 

Systems  Fechnology 
Forecast 

Emerging  technologies  and  software-hardware 
products  that  are  expected  to  be  available  in  a  given 
set  of  time  frames,  and  that  will  affect  future 
development  of  the  architecture 

SV-lOa 

Systems  Rules 

Model 

One  of  three  products  used  to  describe  systems 
activity  sequence  and  timing — constraints  that  are 
imposed  on  systems  functionality  due  to  some 
aspect  of  systems  design  or  implementation 

SV-1  Ob 

Systems  State 

Transition 

Description 

One  of  three  products  used  to  describe  systems 
activity  sequence  and  timing — responses  of  a 
system  to  events 

SY-lOc 

Systems  Event- 
Trace  Description 

One  of  three  products  used  to  describe  systems 
activity  sequence  and  timing — system-specific 
refinements  of  critical  sequences  of  events  and  the 
timing  of  these  events 

SV-1! 

Physical  Schema 

Physical  implementation  of  the  Logical  Data 

Model  s  information  (e.g.,  message  formats,  file 
structures,  physical  schema) 
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Table  1:  Architectural  Products  [C4ISRAF  97]  (continued) 


Applicable 

View 

Framework 

Product 

Framework  Product 
Name 

General  Description 

Technical 

TY-1 

Technical 

Standards  Profile 

Extraction  of  standards  that  apply  to  the  given 
architecture 

TY-2 

Technical 

Standards  Forecast 

Description  of  emerging  standards  that  are 
expected  to  apply  to  the  given,  architecture,  within 
an  appropriate  set  of  time  frames 
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